# GNAP IETF 116 Yokohama   {#gnap-ietf-116-yokohama}

## Agenda   {#agenda}

    Welcome & Note Well (chairs) - 10 min.
    SPC extension to GNAP (Adrian Hope Bailie) - 10 min
    Status/PR review for Core Protocol and Resource Server docs (Justin) - 50 min.
    Working group next steps - 15 min.

## Welcome & Note Well   {#welcome--note-well}

Chairs open meeting and bid welcome. No agenda changes.

## SPC extension   {#spc-extension}

Adrian (from fynbos) presents a slide deck about the SPC extension to
GNAP.

The [SPC specification][1] is hosted at W3C Web Payments WG and is
evolving and welcoming feedbacks.

SPC = secure payment confirmation, to authorize payments through a GNAP
AS and is integrated with webauthn.

It is supported in chrome based browsers with strong support from
Google. The browser APIs are currently being worked on. The UI provides
information on the origin of the merchant, the payment instrument label
and the total. Recurring payments are challenging but in the scope.

Adrian has questions on how custom data (such as a browser fingerprint)
can be passed to the grant request. Justin has been providing support.

Fynbos proposed an opinionated access token format and payment URLs.

Is there more interest in a generic support of webauthn in GNAP?

Yaron question - why do we need a new start mode? It doesn't fit in
existing interaction modes. It could be generalized into webauthn
interaction type. The parameters are different.

Fabien: what's the relationship to interledger? What about phising
payment URLs.   
No direct relationship to interledger (which was an early experiment) /
openpayments (RS URLs protected by GNAP). The payment URL is the
entrypoint to the RS, protected by GNAP and the security considerations
of GNAP apply.

Adrian Gropper: how can we enhance the request with a deposit component?
SPC is an interaction mode, it could be possible that one could make it
a request for payment. The entity paying for the grant is assumed to be
the payer.

## Editors' presentation   {#editors-presentation}

Justin presents the update to the core and RS draft.

### On the core draft   {#on-the-core-draft}

*   The default hash mechanism is now SHA256.

*   The IANA registry actions are clarified.

*   The key rotation was further simplified and secured, by removing
    previous\_key.

*   WGLC comments were responded. Thank you for all that participated.
    There's a few open questions remaining that will be discussed in the
    rest of the presentation.

### On the RS draft:   {#on-the-rs-draft}

*   The token format is proposed. It is designed to be informative,
    helpful to developers and referenced by other systems that depend on
    GNAP.

Yaron question: how normative should that be? what is tied to
security/privacy considerations?

Justin: All tokens have a value (so that's mandatory), but for instance
does the token need to remember who issued it? It's more a data model,
so it depends on the needs. But the security/privacy consideration is
very relevant.

### Token management endpoint   {#token-management-endpoint}

An alternative is proposed: pass token value as a body parameter, pass
that to the token management endpoint and a secondary token is issued
(optional or mandatory?). We have precedents for such behaviour in the
spec and we can extend it to token management. The editors think it
could be a worthwhile normative change.

Chairs: ok for the change, and avoid the optionality.

### Multiple finish methods   {#multiple-finish-methods}

An extension could defined a multi finish mode if there's interest
(tagged as "needs text"). The client would still get a single response.

Yaron: how can it be provided as an extension?

The finish method is an object with a type. An extension could define an
array or a method with multiple types, depending on the chosen syntax.

Chairs: defer it right now.

### GNAP core status   {#gnap-core-status}

Editors' view: ready soon for IETF last call.

Chairs: will need to review token rotation, but doesn't require a 2nd
WGLC.

A new revision will be generated soon.

Do we need an interim meeting? Yes for token rotation. Schedule within a
month.

### What about the RS draft?   {#what-about-the-rs-draft}

There are still issues but it is much simpler than core, mostly we need
to check consistency. We should be able to have the RS ready by IETF in
July.

### Implementations   {#implementations}

Gen digital published its implementation.

Does it make sense to plan an interop session or hackathon at IETF
summer?

Might have a plan to adapt the conformance suite to GNAP.



[1]: https://www.w3.org/TR/secure-payment-confirmation/