length is a uint defined by the application <del> PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. </del> The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same

length is a uint defined by the application  The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same


(method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then <del> mac_length_2 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del>  ID_CRED_R - identifier to facilitate the retrieval of CRED_R, see

I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.

(method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then  <ins> mac_length_2 is equal to hash_length. </ins> ID_CRED_R - identifier to facilitate the retrieval of CRED_R, see


(method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then <del> mac_length_3 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del>  ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see

(method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then  <ins> mac_length_3 is equal to hash_length. </ins> ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see


4. <del> Applications MUST use external PSKs that adhere to the following requirements: Each PSK MUST be derived from at least 128 of entropy and MUST be at least 128-bits long unless the TLS handshake is being used with a separate key establishment mechanism such as a Diffie-Hellman exchange.  This recommendation protects against passive attacks using exhaustive search of the PSK. </del>  Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

This builds on .
Summary: use a high-entropy PSK with DH, otherwise, with a low-entropy PSK, use a PAKE. Reference appendix with security properties from NAME

4.  <ins> Applications MUST adhere to the following requirements for external PSKs: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a


violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable <del> for multiple clients or multiple servers share a PSK.  If this is </del>  done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious

FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable  <ins> for multiple clients or multiple servers to share a PSK.  If this is </ins> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious


appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks. </del>  In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when  <ins> using external PSKs to mitigate these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can


constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. <del> Some devices are provisioned PSKs via an out-of-band, cloud-based </del>  syncing protocol. Some secrets may be baked into or hardware or software device

constrained UI.  Moreover, PSK production lacks guidance unlike user passwords.  <ins> Some devices provision PSKs via an out-of-band, cloud-based </ins> syncing protocol. Some secrets may be baked into or hardware or software device


Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH <del> exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </del>  Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH  <ins> exchange for forward secrecy.  As discussed in sec-properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided.  Low entropy keys are only secure against active attack if a Password Authenticated Key Exchange (PAKE) is used with TLS. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a


6.1. <del> Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </del>  OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. <del> These callbacks must provide a PSK identity (as a character string) and key (as a byte string).  (If no identity is provided, a default one is assumed.)  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </del>  mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. <del> Servers must implement callbacks similar to that of OpenSSL.  PSK lengths are validate to be between [1, 16] bytes. </del>  gnuTLS: Applications configure PSK values, either as raw byte <del> strings or hexadecimal strings.  The PSK size is not validated. </del>  wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.

6.1.  <ins> Most major TLS implementations support external PSKs.  Stacks supporting external PSKs provide interfaces that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </ins> OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake.  <ins> These callbacks must provide a PSK identity and key.  The exact format of the callback depends on the negotiated TLS protocol version with new callback functions added specifically to OpenSSL for TLS 1.3 RFC8446 PSK support.  The PSK length is validated to be between [1, 256] bytes.  The PSK identity may be up to 128 bytes long. </ins> mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline.  <ins> Servers must implement callbacks similar to that of OpenSSL.  Both PSK identity and key lengths may be between [1, 16] bytes long. </ins> gnuTLS: Applications configure PSK values, either as raw byte  <ins> strings or hexadecimal strings.  The PSK identity and key size are not validated. </ins> wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.


Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. <del> [[OPEN ISSUE: discuss implication of collisions between external and resumption PSKs.]] </del>  7.

Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions.  <ins> 6.1.2. It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. </ins> 7.


indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used.  This is in contrast to methods <del> like RTX RFC4588 or flexfec I-D.ietf-payload-flexible-fec-scheme retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. </del>  Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low, and SHOULD

Ah, I see now. I think what would help is "in contrast to methods like RTX or flexfec (when retransmissions are used) [I-D.]"

indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used.  This is in contrast to methods  <ins> like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload- flexible-fec-scheme, Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra roundtrip. </ins> Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low, and SHOULD


This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous <del> packet, or for codecs that support variable-bitrate encodings, </del>  possibly a smaller, lower-quality representation.  In certain cases, <del> the redundant data could include multiple prior packets. </del>  Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant

It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.

This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous  <ins> payload, or for codecs that support variable-bitrate encodings, </ins> possibly a smaller, lower-quality representation.  In certain cases,  <ins> the redundant data could include encodings of multiple prior audio frames. </ins> Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant


Some audio codecs, notably Opus RFC6716 and AMR RFC4867, support their own in-band FEC mechanism, where redundant data is included in <del> the codec payload. </del>  <del> For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery </del>  of a lost packet.  This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed <del> is about 20-30%, depending on the amount of protection needed.  Note that this mechanism can only carry redundancy information for the immediately preceding packet; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </del>  For AMR/AMR-WB, packets can contain copies or lower-quality encodings <del> of multiple prior audio frames.  This mechanism is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, Section 3.7.1 for details on this mechanism. </del>  In-band FEC mechanisms cannot recover any of the RTP header.

Some audio codecs, notably Opus RFC6716 and AMR RFC4867, support their own in-band FEC mechanism, where redundant data is included in  <ins> the codec payload.  This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient. </ins>  <ins> For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery </ins> of a lost packet.  This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed  <ins> is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </ins> For AMR/AMR-WB, packets can contain copies or lower-quality encodings  <ins> of multiple prior audio frames.  See RFC4867, Section 3.7.1 for details on this mechanism. </ins> In-band FEC mechanisms cannot recover any of the RTP header.


Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described <del> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1, as an </del>  additional supported media type for the associated m= section in the SDP offer RFC3264.  As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group,

Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described  <ins> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1.2, as an </ins> additional supported media type for the associated m= section in the SDP offer RFC3264.  As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group,


result MAY be used by the client instance in the request- capabilities of the request. <del> OPTIONAL.  A list of the AS's interaction methods.  The values of this list correspond to the possible fields in the request- interact of the request. </del>  OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the

The discovery fields for the interaction methods were still in a single list, even though those have now been split into start and finish sections.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 754d971b07753b2b9580c2c6f0b3c8997c34b260 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Yes, makes sense

result MAY be used by the client instance in the request- capabilities of the request.  <ins> OPTIONAL.  A list of the AS's interaction start methods.  The values of this list correspond to the possible values for the request-interact-start of the request. OPTIONAL.  A list of the AS's interaction finish methods.  The values of this list correspond to the possible values for the method element of the request-interact-finish of the request. </ins> OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the


Mutual TLS certificate verification <del> OAuth Demonstration of Proof-of-Possession key proof header </del> HTTP Signing signature header OAuth PoP key proof authentication header

remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now

Mutual TLS certificate verification  HTTP Signing signature header OAuth PoP key proof authentication header


7.3.4. <del> This method is indicated by "dpop" in the "proof" field.  The signer creates a Demonstration of Proof-of-Possession signature header as described in I-D.ietf-oauth-dpop section 2.  In addition, this specification defines the following fields to be added to the DPoP payload: Digest of the request body as the value of the Digest header defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. In this example, the request body is the following JSON object: ~~~ { "access_token": { "access": [ "dolphin-metadata" ] }, "interact": { "start": ["redirect"], "finish": { "method": "redirect", "uri": "https://client.foo/callback", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }, "client": { "proof": "dpop", "key": { "jwk": { "kid": "gnap-rsa", "kty": "RSA", "e": "AQAB", "alg": "RS256", "n": "hYOJ- XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_ 3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ" } } "display": { "name": "My Client Display Name", "uri": "https://client.foo/" }, } } ~~~ The JOSE header contains the following parameters, including the public key: The JWS Payload contains the following JWT claims, including a hash of the body: This results in the following full HTTP message request: The verifier MUST parse and validate the DPoP proof header as defined in I-D.ietf-oauth-dpop.  If the HTTP message request includes a message body, the verifier MUST calculate the digest of the body and compare it to the "htd" value.  The verifier MUST ensure the key presented in the DPoP proof header is the same as the expected key of the signer. 7.3.5. </del> This method is indicated by "httpsig" in the "proof" field.  The sender creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures.

7.3.4.  This method is indicated by "httpsig" in the "proof" field.  The sender creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures.


The verifier MUST validate the signature against the expected key of the signer. <del> 7.3.6. </del>  This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I-

The verifier MUST validate the signature against the expected key of the signer.  <ins> 7.3.5. </ins> This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I-


If the client instance is capable of directing the end-user to a URL defined by the AS at runtime, the client instance indicates this by <del> sending the "redirect" field with the boolean value "true".  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </del>  If this interaction mode is supported for this client instance and request, the AS returns a redirect interaction response response-

The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:

If the client instance is capable of directing the end-user to a URL defined by the AS at runtime, the client instance indicates this by  <ins> including "redirect" in the array under the "start" key.  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console. While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </ins> If this interaction mode is supported for this client instance and request, the AS returns a redirect interaction response response-


If the client instance can open a URL associated with an application on the end-user's device, the client instance indicates this by <del> sending the "app" field with boolean value "true".  The means by </del>  which the client instance determines the application to open with this URL are out of scope of this specification.

If the client instance can open a URL associated with an application on the end-user's device, the client instance indicates this by  <ins> including "app" in the array under the "start" key.  The means by </ins> which the client instance determines the application to open with this URL are out of scope of this specification.


If the client instance is capable of displaying or otherwise communicating a short, human-entered code to the RO, the client <del> instance indicates this by sending the "user_code" field with the boolean value "true".  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </del>  contents, composition, or relationship to the AS grant URL. If this interaction mode is supported for this client instance and

If the client instance is capable of displaying or otherwise communicating a short, human-entered code to the RO, the client  <ins> instance indicates this by including "user_code" in the array under the "start" key.  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </ins> contents, composition, or relationship to the AS grant URL. If this interaction mode is supported for this client instance and


ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del>  statement asserted by an AS about a subject.

Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0d7a49a6be4a9740f850d2477b1f2462de781b10 Inspect the deploy log: Browse the preview:
Section 2.2 is currently called: Then the text continues with: This means that this section is currently restricted to the RO. Since this call is restricted to the RO, the title of this section should be changed into: Requesting RO Information. In addition, the reason(s) for requesting such information is not mentioned and should be explained. As a side-consequence, a user has no on-line means to know which personal data the AS knows. This comment also impacts the content of section 1.4.6 (Requesting User Information). This topic has been first addressed under the issue which is still open. It would be wise to allow such an on-line access so that the user can know which attributes are known by an AS and then choose which attributes to insert into an access token.
Maybe we'll need a bit of rewording, although I'm not sure the proposed changes help so much. I just think we should put more emphasis (and state early on) what is shortly described at the end of section 4, i.e. that here RO = end-user
RO = end-user is not the general case. The usefulness of supporting Requesting RO Information is not crystal clear and should be indicated, but there is an interest to support Requesting User Information. While I agree with you that "we'll need a bit of rewording", simply stating that RO = end-user in section 4 will not solve the issue.
I notice that states It also shows that there is no RS involve and diagram uses label: User (not RO) To my understanding End-user is "logged in" to the client instance. Given role definition: If we don't have RS involved, so we also don't have any Protected Resource here, does it really make sense to speak of Resource Owner?
Yes, that's why we talk about the "user" here. Notice that currently, this term is used when we don't know the exact role it will play in the protocol (end user or RO).
If that's the case for why does speak about Resource Owner? Again in 2.2 we also don't seem to have Resource Server or Protected Resource involved.
The rationale is : in the intro of section 4, gnap allows a large variety of cases. GNAP can handle UMA2 types of scenarii (hence 1.4.6 and a few other places) but in gnap core we mostly detail the case where end-user = RO. Hence what we explain about the subject, and it makes sense to limite the diffusion of confidential information about the RO (the most limiting case, hence 2.2 and a few other places) That's actually a quite subtle difference, but i think it makes good sense.
Given above definitions maybe it would make sense to broaden definition of RO to: subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon. Since in the User acting as RO doesn't grant or deny operations on resources (served by RS) but only grants / denies obtaining an assertion.
I agree that the specific language that NAME references should be tightened up. What's a little awkward right now is that GNAP's language treats access to an RS and access to information contained in assertions as protected resources, but it doesn't do so particularly cleanly due to several major text revisions that have changed things a little out of sync with each other. Both data from an RS (using an access token) and assertions/identifiers passed to the client are targeted at the client itself, so in that way they're the same nature, a protected resource after a fashion and both controlled by an RO of some kind. What's different is that the info passed back directly is usually assumed to be :about: the end-user, because that's what the client is calling about in just about all the use cases that are known. Technically all of the information, either from an RS or subject information passed directly, is controlled by the RO. The end-user can get involved through interaction and act as the RO. The case where the RO doesn't equal the end-user is useful in many situations but leads to unexpected weirdness when you're talking about the subject information coming back.
Fair point. We might start by listing what needs to be changed.
I tend to think of the AS as having a separate service endpoint for RO requests because they are the ones that can edit AS policy. A service endpoint that is accessible to End User requests would be "separate" and could be used by anyone including the RO when they want the protection of least-privilege. This distinction may be unhelpful in the general case of explaining GNAP so I don't mean to overstate it.
NAME when you say "service endpoint" are you thinking of something that's interactive and user-facing (so a webpage) or something that's a callable API?
NAME I really don't know enough to answer purely technical questions. I think mostly in terms of privacy engineering and look to this group for security and devops perspective. Therefore, I focus on the AS as the primary, if not the sole, entity that stores and executes RO policy. The AS takes requests and turns them into access tokens. The requests might be via (RAR) API or a web form. Either way, this request interface is likely unsecured. Some requests present credentials while others might add an authentication flow. That begs the issue of how did the AS get the RO's policies to begin with, long before a request comes in? I would define whoever sets the AS policies as the RO (regardless of any particular RS-RO relationship). A so-called "policy manager API" has been under discussion in UMA for about a year because at least one implementer wants to author policies on a mobile app and standardize the way they are uploaded to the AS. Back to Justin's technical question, I'm trying to implement the shortest distance between OAuth 2 and GNAP in a way that I can understand and explain to others. I'm doing this in FastAPI (because I don't know much beyond elementary Python, because it has built-in OpenAPI documentation, and has some OAuth 2 and JWT functionality). I'm deploying (automagically) to DigitalOcean App Platform in order to be clear about my various security and build shortcuts. I've designed the demo as two separate FastAPI server domains for the RS and AS. A "global" CouchDB instance is deployed for RO policy storage and any state that needs to be saved as part of the protocol demos. -- URL (the AS) and running at https://ognap-URL -- URL and running at https://ognap-rs-URL -- URL The protected resource is going to be_ just a self-verifying vaccine credential (I invented) -- URL -- Some of this is running at URL I've been stuck trying to answer Justin's exact question for quite a while. I think I need to set up the AS (OGNAP) to deliver a PWA to the RO so they can edit policies locally in PouchDB and sync the polices with the CouchDB the AS can access when a request comes in. That forces me to learn URL or something like it. Aside from my long-term goal to upgrade the HIE of One Trustee demo from UMA to GNAP, I'm also hoping to show the W3C and DIF protocol groups how easy it could be to mitigate significant OAuth 2 human rights concerns using GNAP. Any suggestions, help, moral support would be really welcome.
back to NAME and NAME : looking again on this. I guess we could define what we mean by operations. Getting an assertion is an operation, in my view. Or give it as an example. What do you think ?
I think it comes down to whether or not we consider the "subject information", which includes both identifiers and assertions, to be "resources" or not. I always thought they are, but they are definitely a different style of resource than what comes from the RS so maybe we need better wording around it. We talked about it a bit in the long terminology discussion a year ago, but I don't think we ever really landed on a term that fully captures "stuff sent directly to the client by the AS and not accessed through the RS". Identifiers and assertions are the two categories where there's clear demand, but other things could happen through extensions as well.
Does this issue also have to align with authentication flows that build on GNAP? a subject presents a DID or other identifier to a relying party (RP) the RP dereferences the identifier to an AS they trust a request for assertion is made to the AS the AS issues a liveness challenge to the subject the AS returns an assertion and attributes to the RP (the attributes might be accessed indirectly via an access token returned with the assertion) How is SIOP planning to handle this?
In the current draft, section 2.2 : "The AS can determine the RO's identity and permission for releasing this information through interaction with the RO (Section 4), AS policies, or assertions presented by the client instance (Section 2.4). If this is determined positively, the AS MAY return the RO's information in its response (Section 3.4) as requested." Currently, a resource is just a short cut for "Protected resource", which really refers to an API served by a RS. So we have a mismatch (or at least a missing case) in the RO definition (as pointed out by NAME and NAME I've tried some sentences to specify subtypes for resources, but it becomes very confusing. The proposal by NAME to define the RO as "subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon." seems slightly incorrect to me, because the assertion is not made by the RO, but by the AS. What the RO grants to the AS is access to its attributes (and then the AS may carry out further due diligence to derive assertions, for instance through AuthN flows as suggested by NAME The decision to disclose or not its own attributes is not restricted to the RO, it's actually something under the control of every subject. So here's what I'd suggest to solve the issue (new part in bold): update the definition of "Subject: person, organization or device. It decides whether and under which conditions its attributes can be disclosed to other parties." question 1 : should we limit this to physical persons? (from a legal perspective, that makes sense, but then wouldn't an org want to restrict what it shares, cf issues around data sovereignty?). I think the principle could be generic. question 2 : I've added under which conditions because we already discuss that in the text (manual consent, automatic policy, etc.), plus it's not only a yes/no, it also concerns what those other parties can do with it, including further sharing those attributes, cf the case mentioned by NAME where the AS sends them to the RP. Feedback welcome !
section refers to the Subject exclusively as RO. I'm still uncertain if the subject who in interaction only decides to disclose some attributes in an but not any "Protected resources" (an API served by RS) is considered to act as RO. If that's the case what would be the case where the subject decides to disclose some attributes but doesn't act as RO?
I'm not entirely sure about the use case you're targeting here. Could you be more specific ?
Maybe I shouldn't have mixed two questions together. Let's focus on one of them first. section always refers to the Subject as RO. In your previous comment you mentioned that: When we would have a situation where a Subject is deciding to disclose its own attributes but they don't act as RO?
In theory section 4 allows other situations (at the beginning of the section). But the only case that's detailed is the case where it is indeed the RO.
Thanks, now for the second part of my question. In we find: In this scenario, while no RS is participating, so no Protected Resources are being accessed. We still have Shouldn't definition of RO should still be broadened from current Keeping in mind It might still be something in direction of subject entity that may grant or deny operations on resources or obtaining assertions containing attributes it has authority upon. In short, if RO plays role in . There seems to be more to that role than just granting or denying operations on resources (an API served by RS).
My view is that the attribute part is covered by the fact that the RO is a subject (obtaining them is covered by the subject definition now). The main rationale for the protocol is still related to access to protected resources, and I believe we would dilute that otherwise.
In that case is there any reason for to still include: I think 4 could be removed altogether and 5 could become (after renumbering) This section states in the first sentence that it does not involve RS and access to protected resources (an API served by RS)
We still need to make sure that the user is indeed the RO, hence step 4.
I still consider that the information about the subject is counted among the "Resources" being released here. The only real difference is that instead of them being at an RS, they're passed directly to the client instance.
Yes, this didn't change. I'm only saying I don't think it needs to be embedded into the RO definition, since we can assume from the subject definition itself that some mechanism exists to grab the subject attributes data if it consents to. Changing the RO definition or worse the (protected) resource definition makes the entire thing convoluted, at least in every variation I tried.
NAME Right, and I think I agree with that. The definitions should try to stay tight, if we can. But if the surrounding text, especially the "subject information" request stuff isn't clear, then this is going to come around again. I don't have a specific answer but I would be surprised if we can't improve this, since it's come up a few times.
I am supportive of elf-pavlik when he writes: fimbault agrees with him when he says: When looking at Section 3.4 that is indicated in that section, the following text may be found. If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information in the "subject" response field. The case where information is about the end-user is not addressed, i.e. there is no sentence starting with: If information about the end-user is requested (...) Does this mean that an end-user is not allowed to know which personal data is known by the AS about him ? If this would be the case, such a limitation would not comply with generally agreed privacy principles. The text is still not fixed in draft-08. What are the benefits for a client to know information about the RO ? This may be crystal clear for the editor(s), but it is unclear for a lambda reader.
Based on recent conversations, especially URL it seems to me that the intention is to consider the subject as RO with regards to the information about them. I think this shows up clearly in since it does not involve any Protected Resources but it stills call the user RO. It might be helpful to document scenarios where there is more than one AS involved. Let's say we have Alice using a client to access resources owned by Bob. Here we could have two different AS: AS providing user information about Alice to the client - here Alice would act as both End-user and RO and Bob not be involved at all AS providing access_token to the client allowing access for protected resources - here Alice would act as End-user and Bob as RO Does that scenario with two different Authorization Servers sound reasonable?
NAME Those two both make sense, and it makes sense even for them to be together. You could have those be the same AS as well, if Bob's resource server is protected by the same server Alice is using to log in to the client. But they're different kinds of access, and it would make sense to talk about them in a single example scenario to help call out that difference. There's also a weird case from the CIBA work in the OIDF: Alice uses client software to find out who Bob is. The canonical example given here is a call center: Alice needs to verify that the person calling her is actually Bob, and so Alice starts something with the AS that reaches out to Bob to approve the release of identity information about Bob to Alice, in real time.
NAME how does Alice know which AS can release identity information about Bob? I would not make an assumption that one global central AS exists and it has information about the whole Earth's population?
NAME This use case is not assuming a global AS at all (I agree, that's absurd), but it is assuming that Alice and Bob are both working with a known ecosystem. In the case of the call center example, it's the supporting company's AS -- where Alice works and where Bob is a customer. So, Bob needs to have an account there, and so does Alice. Alice's account needs to be authorized to get info about other users (because she's a support tech). Bob's account is a customer account that Alice can fetch information from anyway.
I see, thank you. It indeed looks like another use case where Bob acts as RO but there is no RS or Protected Resource involved.
I've encountered the CIBA use case very recently. Here's a summarised description : the enduser gets in touch (out of band) with the support, so that both are available at the same time the support needs to get read access to some info stored on the enduser's mobile, and uses CIBA to get the enduser's approval returned scopes define what can be accessed through another OIDC client (used by the support agent) there are no RS involved Note : this issue is closed, so either we should reopen it or open a new issue
NAME Agreed, we've drifted off of the topic of the issue as well. I opened up a new issue for discussion of the cross-user CIBA use case specifically:

ability given to a subject to perform a given operation on a resource under the control of an RS.  <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.


as far as the overall protocol is concerned. A single role need not be deployed as a monolithic service.  For <del> example, A client instance could have components that are installed </del>  on the end user's device as well as a back-end system that it communicates with.  If both of these components participate in the delegation protocol, they are both considered part of the client

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

as far as the overall protocol is concerned. A single role need not be deployed as a monolithic service.  For  <ins> example, a client instance could have components that are installed </ins> on the end user's device as well as a back-end system that it communicates with.  If both of these components participate in the delegation protocol, they are both considered part of the client


In some circumstances, the information needed at a given stage is communicated out of band or is preconfigured between the components <del> or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </del>  1.5.1.

In some circumstances, the information needed at a given stage is communicated out of band or is preconfigured between the components  <ins> or entities performing the roles.  For example, one entity can fulfill multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </ins> 1.5.1.


The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction- <del> redirect given by the AS in (2). </del>  <del> The user's directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </del>  documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a

The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-  <ins> usercode given by the AS in (2). </ins>  <ins> The users directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </ins> documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a


The client instance request.  The client instance does not send any interaction modes to the server. <del> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to the client instance.  Note that response-subject is not generally </del>  applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.

The client instance request.  The client instance does not send any interaction modes to the server.  <ins> The AS determines that the request has been authorized, the AS grants access to the resource in the form of response-token to the client instance.  Note that response-subject is not generally </ins> applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.


the RS again. The RS validates the access token and determines that the access <del> token is expired The RS responds to the client instance with an </del>  error. The client instance calls the token management URI returned in (2)

the RS again. The RS validates the access token and determines that the access  <ins> token is expired.  The RS responds to the client instance with an </ins> error. The client instance calls the token management URI returned in (2)


2. <del> To start a request, the client instance sends RFC8259 document with </del>  an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by <del> extensions to this protocol as described in </del>  A non-normative example of a grant request is below:

2.  <ins> To start a request, the client instance sends a RFC8259 document with </ins> an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by  <ins> extensions to this protocol as described in request-extending. </ins> A non-normative example of a grant request is below:


to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the "client" object.  The instance identifier MAY be assigned to a <del> client instance at runtime through the response-dynamic-handles or MAY be obtained in another fashion, such as a static registration process at the AS. </del>  When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to binding-keys is associated with the

to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the "client" object.  The instance identifier MAY be assigned to a  <ins> client instance at runtime through a grant response (response- dynamic-handles) or MAY be obtained in another fashion, such as a static registration process at the AS. </ins> When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to binding-keys is associated with the


In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed <del> in the sections below </del>  In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.

In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed  <ins> in the sections below. </ins> In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.


it can request-interact-usercode. The AS determines that interaction is needed and response with a <del> response-interact-usercode.  This could optionally include a URI to direct the user to, but this URI should be static and so could be configured in the client instance's documentation.  The AS also includes information the client instance will need to response- continue in (8) and (10).  The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </del>  The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-

Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._

it can request-interact-usercode. The AS determines that interaction is needed and response with a  <ins> response-interact-usercode.  The AS also includes information the client instance will need to response-continue in (8) and (10). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </ins> The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-


any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using <del> the request-user. </del>  The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the

any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using  <ins> the request-user.  It's also possible for the AS to determine which RO needs to be contacted by the nature of what access is being requested. </ins> The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the


response-token-single, the proof of that key MUST be used when presenting the access token. <del> A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of public keys in security-symmetric. A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key. </del>  Additional key formats are defined in the IANA-key-formats. <del> This non-normative example shows a single key presented in multiple formats.  This example key is intended to be used with the httpsig- binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. </del>  7.1.1.

After discussion with NAME , this PR now makes keys single-format-only as previously suggested.
To edit notification comments on pull requests, go to your ._
Yaron: why are we sending a JWK as well as a cert? Are we checking that the cert contains the same public key as the cert? Justin: I would be OK with the different formats being mutually exclusive somehow. The AS would need to check that they’re the same and throw an error if not. But this would also let the RC send over whatever it’s got for its own keys every time.
The document has been changed to address this issue, copying my text that refers to the latest draft version: In Sec. 7.1 we allow the client to include multiple keys of different formats, provided they are "equivalent". This doesn't make sense, because the only reason to send multiple keys is that the sender suspects that the recipient doesn't understand one of the formats. But if that's the case, the recipient is not able to validate the MUST requirement that the two formats be equivalent. This could also lead to interesting key injection attacks. IMO we should only allow one key value/format for each request.

response-token-single, the proof of that key MUST be used when presenting the access token.  <ins> A key presented by value MUST be a public key and MUST be presented in one and only one supported format, as discussed in security- multiple-key-formats.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of the presentation of public keys in security-symmetric. </ins> Additional key formats are defined in the IANA-key-formats.  <ins> This non-normative example shows a single key presented in two different formats.  This example key is intended to be used with the httpsig-binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. As a JSON Web Key: As a certificate in PEM format: </ins> 7.1.1.


SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URI if unsure.  13. The privacy considerations in this section are modeled after the list

SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URI if unsure. <ins> 12.33. Keys presented by value are allowed to be in only a single format, as discussed in key-format.  Presenting the same key in multiple formats is not allowed and is considered an error in the request.  If multiple keys formats were allowed, receivers of these key definitions need to be able to make sure that it's the same key represented in each field and not simply use one of the key formats without checking for equivalence.  If equivalence were not carefully checked, it is possible for an attacker to insert their own key into one of the formats without needing to have control over the other formats.  This could potentially lead to a situation where one key is used by part of the system (such as identifying the client instance) and a different key in a different format in the same message is used for other things, like calculating signature validity. To combat this, all keys presented by value have to be in exactly one supported format known by the receiver.  Normally, a client instance is going to be configured with its keys in a single format, and it will simply present that format as-is to the AS in its request.  A client instance capable of multiple formats can use discovery to determine which formats are supported, if desired.  An AS should be generous in supporting many different key formats to allow different types of client software and client instance deployments. </ins> 13. The privacy considerations in this section are modeled after the list


An example set of protocol messages for this method can be found in example-async.  1.6.5. In this example flow, the AS policy allows the client instance to

Adds the field for requesting information for a specific user, separate from identifying the current end-user. Also adds a security considerations section addressing asynchronous authorization methods.
To edit notification comments on pull requests, go to your .
Normally we think about releasing subject information being about the current end-user, but that's not necessarily universal. The use case from CIBA: Alice is a support engineer with a company Bob is a customer of that company Bob calls the company and talks to Alice Alice needs to authenticate, from her system, that Bob is the person tied to the account in question Alice's client messages the AS to request Bob's information (probably including an identifier for Bob in the request) The AS reaches out to Bob to approve Alice's client to get Bob's information Bob approves Alice's request (probably on a pre-enrolled device) The AS sends Bob's information back to Alice's client Note a few key assumptions with this: At no point does Alice's client think that Bob is logging in. Alice and Bob both need accounts of some type at the AS Alice's account (or client) need the rights to request someone else's info Bob's approval mechanism needs to be tied to his account ahead of time (since Bob isn't running the client and the AS needs to reach out to him out of band) Bob's approval needs to be clearly directed to tell Bob that it's Alice (and alice's client) asking for his info Alice might need to log in / interact with the AS as part of this, or it might be tied to the client instance (maybe Alice has logged in for the day and that association is remembered by the AS?)
This is an interesting use case. Yet CIBA doesn't necessarily require an AS to work, as long as one is only interested in getting scopes. Is there a generic use case for cross-user subject information + required AS? Or maybe we should explain the added value of the AS in that specific case ?
We will add an example in section D that shows how this would work and verify that the language around subject identifiers is sufficiently robust to encapsulate this. This might also add additional security and privacy considerations when used in this mode because multiple people are now involved explicitly.
I think this could be marked as NEEDS TEXT ?
I think it mostly just needs to be added as an example, and I can do that.
Fine ;-) (on my side, I always tend to consider CIBA as some degenerate phishing experiment, but maybe that's too extreme)

An example set of protocol messages for this method can be found in example-async. <ins> Additional considerations for asynchronous interactions like this are discussed in security-async. </ins> 1.6.5. In this example flow, the AS policy allows the client instance to


returned and it might not match what the client instance requested, see the section on subject information for details.  2. To start a request, the client instance sends a RFC8259 document with

returned and it might not match what the client instance requested, see the section on subject information for details. <ins> 1.6.8. In this scenario, the end user and resource owner are two different people.  In this scenario, the client instance already knows who the end user is, likely through a separate authentication process.  The end user, operating the client instance, needs to get subject information about another person in the system, the RO.  The RO is given an opportunity to release this information using an asynchronous interaction method with the AS.  This scenario would apply, for instance, when the end user is an agent in a call-center and the resource owner is a customer authorizing the call center agent to access their account on their behalf. Precondition: The end user is authenticated to the client instance, and the client instance has an identifier representing the end user that it can present to the AS.  This identifier should be unique to the particular session with the client instance and the AS. The RO communicates a human-readable identifier to the end user, such as an email address or account number.  This communication happens out of band from the protocol, such as over the phone between parties.  Note that the RO is not interacting with the client instance. The end user communicates the identifier to the client instance. The means by which the identifier is communicated to the client instance is out of scope for this specification. The client instance request.  The request includes the RO's identifier in the request-subject "sub_ids" field, and the end user's identifier in the request-user of the request.  The request includes no interaction start methods, since the end user is not expected to be the one interacting with the AS.  The request does include the request-interact-callback-push to allow the AS to signal to the client instance when the interaction with the RO has concluded. The AS sees that the identifier for the end user and subject being requested are different.  The AS determines that it can reach out to the RO asynchronously for approval.  While it is doing so, the AS returns a response-continue with a "finish" nonce to allow the client instance to keep polling after interaction with the RO has concluded. The AS contacts the RO and has them authenticate to the system. The means for doing this are outside the scope of this specification, but the identity of the RO is known from the subject identifier sent in (3). The RO is prompted to authorize the end user's request via the client instance.  Since the end user was identified in (3) via the user field, the AS can show this information to the RO during the authorization request. The RO completes the authorization with the AS.  The AS marks the request as . The RO pushes the interaction-pushback to the client instance. Note that in the case the RO cannot be reached or the RO denies the request, the AS still sends the interaction finish message to the client instance, after which the client instance can negotiate next steps if possible. The client instance validates the interaction finish message and continue-after-interaction. The AS returns the RO's response-subject to the client instance. The client instance can display or otherwise utilize the RO's user information in its session with the end user.  Note that since the client instance requested different sets of user information in (3), the client instance does not conflate the end user with the RO. Additional considerations for asynchronous interactions like this are discussed in security-async. </ins> 2. To start a request, the client instance sends a RFC8259 document with


12.34.  An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of

12.34. <ins> GNAP allows the RO to be contacted by the AS asynchronously, outside the regular flow of the protocol.  This allows for some advanced use cases, such as cross-user authentication or information release, but such advanced use cases have some distinct issues that implementors need to be fully aware of before using these features. First, in many applications, the return of a subject information to the client instance could indicate to the client instance that the end-user is the party represented by that information, functionally allowing the end-user to authenticate to the client application. While the details of a fully functional authentication protocol are outside the scope of GNAP, it is a common exercise for a client instance to be requesting information about the end user.  This is facilitated by the several interaction-start defined in GNAP that allow the end user to begin interaction directly with the AS. However, when the subject of the information is intentionally not the end-user, the client application will need some way to differentiate between requests for authentication of the end user and requests for information about a different user.  Confusing these states could lead to an attacker having their account associated with a privileged user.  Client instances can mitigate this by having distinct code paths for primary end user authentication and requesting subject information about secondary users, such as in a call center.  In such use cases, the client software used by the resource owner (the caller) and the end-user (the agent) are generally distinct, allowing the AS to differentiate between the agent's corporate device making the request and the caller's personal device approving the request. Second, RO's interacting asynchronously do not usually have the same context as an end user in an application attempting to perform the task needing authorization.  As such, the asynchronous requests for authorization coming to the RO from the AS might have very little to do with what the RO is doing at the time.  This situation can consequently lead to authorization fatigue on the part of the RO, where any incoming authorization request is quickly approved and dispatched without the RO making a proper verification of the request.  An attacker can exploit this fatigue and get the RO to authorize the attacker's system for access.  To mitigate this, AS systems deploying asynchronous authorization should only prompt the RO when the RO is expecting such a request, and significant user experience engineering efforts need to be employed to ensure the RO can clearly make the appropriate security decision.  Furthermore, audit capability, and the ability to undo access decisions that may be ongoing, is particularly important in the asynchronous case. </ins> An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of


4.2. If an interaction response-interact-finish method is associated with <del> the current request, the AS MUST follow the appropriate method at upon completion of interaction in order to signal the client instance to continue, except for some limited error cases discussed below.  If a finish method is not available, the AS SHOULD instruct the RO to </del>  return to the client instance upon completion. The AS MUST create an interaction reference and associate that

Just two minor typos I stumbled across.
Built To edit notification comments on pull requests, go to your .

4.2. If an interaction response-interact-finish method is associated with  <ins> the current request, the AS MUST follow the appropriate method upon completion of interaction in order to signal the client instance to continue, except for some limited error cases discussed below.  If a finish method is not available, the AS SHOULD instruct the RO to </ins> return to the client instance upon completion. The AS MUST create an interaction reference and associate that


appropriate cryptographic processes to ensure the integrity of the assertion. <del> For example, when SAML 2 assertions are used, the receiver hast to </del>  parse an XML document.  There are many well-known security vulnerabilities in XML parsers, and the XML standard itself can be attacked through the use of processing instructions and entity

appropriate cryptographic processes to ensure the integrity of the assertion.  <ins> For example, when SAML 2 assertions are used, the receiver has to </ins> parse an XML document.  There are many well-known security vulnerabilities in XML parsers, and the XML standard itself can be attacked through the use of processing instructions and entity


usercode and the AS supports this mode for the client instance's request, the AS responds with a "user_code" field.  This field is string containing a unique short code that the user can type into a <del> web page.  This string MUST be case-insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than </del>  eight characters in length. The client instance MUST communicate the "user_code" value to the end

clarify that user codes are unguessable, - update user code examples,
To edit notification comments on pull requests, go to your .
This is very minor, but there's a contradiction between the usercode provided in the example in section 3.3.3. and the recommendations that are mentioned in the text above it. The text says: And However, the example provided below it goes against these two recommendations, as it contains a special character (a hyphen) rather than just letters and numbers, and it's longer than eight characters in length: I'd suggest either tweaking the wording, or tweaking the example so that the usercode provided in the example is aligned to the recommendations mentioned in the text.
The specification does not require user codes to be unguessable. Section 3.3.3 (Display of a Short User Code) states that user codes have to be unique and should be short-lived, but this does not imply that codes should be unguessable. It seems that Section 13.27 (Exhaustion of Random Value Space) does not apply to user codes, but to values that are clearly random values "such as nonces, tokens, and randomized URIs". If attackers can guess user codes, the same attack described in URL is possible.
Good catch! The intent is for these to be unguessable, so we can add that explicitly.

usercode and the AS supports this mode for the client instance's request, the AS responds with a "user_code" field.  This field is string containing a unique short code that the user can type into a  <ins> web page.  To facilitate usability, this string MUST be case- insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The string MUST be randomly generated so as to be unguessable by an attacker within the time it is accepted.  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than </ins> eight characters in length. The client instance MUST communicate the "user_code" value to the end


When the end user is directed to enter a short code through the response-interact-usercode mode, the client instance communicates the user code to the end user and directs the end user to enter that code <del> at an associated URI.  This mode is designed to be used when the client instance is not able to communicate or facilitate launching an arbitrary URI.  The associated URI could be statically configured with the client instance or in the client software's documentation. As a consequence, these URIs SHOULD be short.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </del>  In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and

When the end user is directed to enter a short code through the response-interact-usercode mode, the client instance communicates the user code to the end user and directs the end user to enter that code  <ins> at an associated URI.  The client instance MAY format the user code in such a way as to facilitate memorability and transfer of the code, so long as this formatting does not alter the value as accepted at the user code URI.  For example, a client instance receiving the user code "A1BC3DFF" could choose to display this to the user as "A1BC 3DFF", breaking up the long string into two shorter strings.  In this example, the space in between the two parts would be removed upon its entry into the user code URI. This mode is designed to be used when the client instance is not able to communicate or facilitate launching an arbitrary URI.  The associated URI could be statically configured with the client instance or in the client software's documentation.  As a consequence, these URIs SHOULD be short.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </ins> In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and


When the end user is directed to enter a short code through the response-interact-usercodeuri mode, the client instance communicates the user code and associated URI to the end user and directs the end <del> user to enter that code at the URI.  This mode is used when the client instance is not able to facilitate launching a complex arbitrary URI but can communicate arbitrary values like URIs.  As a consequence, these URIs SHOULD be short to allow the URI to be typed by the end user.  The client instance MUST NOT modify the URI when communicating it to the end user; in particular the client instance MUST NOT add any parameters to the URI.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </del>  In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and

When the end user is directed to enter a short code through the response-interact-usercodeuri mode, the client instance communicates the user code and associated URI to the end user and directs the end  <ins> user to enter that code at the URI.  The client instance MAY format the user code in such a way as to facilitate memorability and transfer of the code, so long as this formatting does not alter the value as accepted at the user code URI.  For example, a client instance receiving the user code "A1BC3DFF" could choose to display this to the user as "A1BC 3DFF", breaking up the long string into two shorter strings.  In this example, the space in between the two parts would be removed upon its entry into the user code URI. This mode is used when the client instance is not able to facilitate launching a complex arbitrary URI but can communicate arbitrary values like URIs.  As a consequence, these URIs SHOULD be short to allow the URI to be typed by the end user.  The client instance MUST NOT modify the URI when communicating it to the end user; in particular the client instance MUST NOT add any parameters to the URI.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </ins> In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and


13.27. Several parts of the GNAP process make use of unguessable randomized <del> values, such as nonces, tokens, and randomized URIs.  Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </del>  generation space.  While this attack is particularly applicable to the AS, client software could likewise be targeted by an attacker triggering new grant requests against an AS.

13.27. Several parts of the GNAP process make use of unguessable randomized  <ins> values, such as nonces, tokens, user codes, and randomized URIs. Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </ins> generation space.  While this attack is particularly applicable to the AS, client software could likewise be targeted by an attacker triggering new grant requests against an AS.


This specification defines the following interaction start modes:  Additional start modes are defined in the IANA-interaction-start- modes.

NAME Please take a look at this updated text to see if it addresses your concerns.
To edit notification comments on pull requests, go to your .
Thinking about possible extensions to GNAP's interaction modes, I had the impression that the specification could be a bit clearer regarding requirements on such extensions. From reading Section 3.3, my understanding is that all implementations of GNAP, including ones using extensions which define additional interaction finish methods, MUST include a nonce in the grant response (given that the AS wants to use the finish method offered by the client instance): URL However, Section 3.3.5 sounds a bit different, only referring to the two interaction finish methods defined by GNAP core: URL Section 4.2 could be a bit clearer as to what is expected of future extensions to GNAP, it currently says: URL with the two following sections describing the finish methods defined by GNAP core. This is, however, somewhat clearer in Section 4.2.3: I.e., Section 4.2.3 implies that AS must (somehow) provide the client instance with an interaction reference and interaction finish nonce. But it may be helpful to make this more explicit throughout the relevant Sections. There seem to be no requirements for future interaction start methods. It may be helpful to document some minimal requirements, e.g., enough information to identify the grant has to be conveyed to AS via RO in the interaction start (such as the redirect URI in GNAP core).
Thanks NAME for taking the time! The proposed text looks good to me (just one possible typo, I'm not a native speaker, so I'm not 100% sure about that).

This specification defines the following interaction start modes: <ins> All interaction start method definitions MUST provide enough information to uniquely identify the grant request during the interaction.  In the "redirect" and "app" modes, this is done using a unique URI (including its parameters).  In the "user_code" and "user_code_uri" mode, this is done using the value of the user code. </ins> Additional start modes are defined in the IANA-interaction-start- modes.


methods: If interaction finishing is supported for this client instance and <del> request, the AS response-interact-finish used by the client instance to validate the callback.  Requests to the callback URI MUST be processed as described in interaction-finish, and the AS MUST require presentation of an interaction callback reference as described in continue-after-interaction. </del>  2.5.2.1.

methods: If interaction finishing is supported for this client instance and  <ins> request, the AS will response-interact-finish used by the client instance to validate the callback.  All interaction finish methods MUST use this nonce to allow the client to verify the connection between the pending interaction request and the callback.  GNAP does this through the use of the interaction hash, defined in interaction- hash.  All requests to the callback URI MUST be processed as described in interaction-finish. All interaction finish methods MUST require presentation of an interaction reference for continuing this grant request.  This means that the the interaction reference MUST be returned by the AS and MUST be presented by the client as described in continue-after- interaction.  The means by which the interaction reference is returned to the client instance is specific to the interaction finish method. </ins> 2.5.2.1.


hash.  The client instance will use this value to validate the "finish" call. <del> The AS MUST send the hash and interaction reference based on the interaction finish mode as described in the following sections. </del>  Note that in many error cases, such as when the RO has denied access, the "finish" method is still enacted by the AS.  This pattern allows

hash.  The client instance will use this value to validate the "finish" call.  <ins> All interaction finish methods MUST define a way to convey the hash and interaction reference back to the client instance.  When an interaction finish method is used, the client instance MUST present the interaction reference back to the AS as part of its continue- after-interaction. </ins> Note that in many error cases, such as when the RO has denied access, the "finish" method is still enacted by the AS.  This pattern allows


3.1. A GNAP AS offering RS-facing services can publish its features on a <del> well-known discovery document using the URL ".well-known/gnap-as-rs". </del>  <del> This endpoint contains a JSON document RFC8259 consisting of a single JSON object with any combination of the following optional fields: </del>  <del> The URL of the endpoint offering introspection. </del>  A list of token formats supported by this AS. <del> The URL of the endpoint offering resource registration. The grant endpoint of the GNAP AS. </del>  3.2.

Expands the discovery document and aligns it with changes made to the discovery process in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: ac397efc4f491e2003a3f8059eef765b8e3075b3 :mag: Inspect the deploy log: :sunglasses: Browse the preview:

3.1. A GNAP AS offering RS-facing services can publish its features on a  <ins> well-known discovery document using the URL ".well-known/gnap-as-rs" appended to the grant request endpoint URL. </ins>  <ins> The discovery response is a JSON document RFC8259 consisting of a single JSON object with the following fields: </ins>  <ins> OPTIONAL.  The URL of the endpoint offering introspection.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. </ins> A list of token formats supported by this AS.  <ins> The URL of the endpoint offering resource registration.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. REQUIRED.  The location of the AS's grant request endpoint, used by the RS to derive downstream access tokens.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST be the same URL used by client instances in support of GNAP requests. OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the "proof" field of the key section of the request. </ins> 3.2.


If the RS needs to, it can post a set of resources as described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol to <del> the AS's resource registration endpoint. </del>  The RS MUST identify itself with its own key and sign the request. <del> The AS responds with a handle appropriate to represent the resources list that the RS presented. </del>  <del> The RS MAY make this handle available as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to developers. </del>  <del> [[ See issue #117 [2] ]] </del>  4.

Expands the definition of the resource set registration protocol, used by an RS to declare a resource set to an AS at runtime and receive a reference identifier for that resource set to hand to a client.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: f9aac0b2af163c0f9a58ba17e93db7e8956140bf :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Registering a Resource Handle: Editor's note: It's not an exact match here because the "resource_handle" returned now represents a collection of objects instead of a single one. Perhaps we should let this return a list of strings instead? Or use a different syntax than the resource request? Also, this borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol

If the RS needs to, it can post a set of resources as described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol to  <ins> the AS's resource registration endpoint along with information about what the RS will need to validate the request. REQUIRED.  The list of access rights associated with the request in the format described in the "Resource Access Rights" section of I-D.ietf-gnap-core-protocol. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The token format required to access the identified resource.  If the field is omitted, the token format is at the discretion of the AS.  If the AS does not support the requested token format, the AS MUST return an error to the RS. OPTIONAL.  If present and set to "true", the RS expects to make a token introspection request as described in introspection.  If absent or set to "false", the RS does not anticipate needing to make an introspection request for tokens relating to this resource set. </ins> The RS MUST identify itself with its own key and sign the request.  <ins> The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests. REQUIRED.  A single string representing the list of resources registered in the request.  The RS MAY make this handle available to a client instance as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to client software developers. </ins>  <ins> OPTIONAL.  An instance identifier that the RS can use to refer to itself in future calls to the AS, in lieu of sending its key by value. </ins>  <ins> OPTIONAL.  The introspection endpoint of this AS, used to allow the RS to perform token introspection. </ins> 4.


itself with its own key in the "client" field and sign the request just as any client instance would. <del> [[ See issue #116 [3] ]] </del>  The AS responds with a token for the downstream RS2 as described in I-D.ietf-gnap-core-protocol.  The downstream RS2 could repeat this

itself with its own key in the "client" field and sign the request just as any client instance would.  <ins> [[ See issue #116 [2] ]] </ins> The AS responds with a token for the downstream RS2 as described in I-D.ietf-gnap-core-protocol.  The downstream RS2 could repeat this


[1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 <del> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/117 [3] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </del>

[1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115  <ins> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </ins>


The RS signs the request with its own key and sends the access token as the body of the request.  The AS responds with a data structure describing the token's current state and any information the RS would need to validate the token's presentation, such as its intended proofing mechanism and key <del> material.  The response MAY include any fields defined in an access token response. </del>  3.4.

Updates token introspection definitions into a more full protocol offered by the AS.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 0b6505e11547ab68388ce27ffc88a8e1c9e5c16b :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Introspecting a Token: Editor's note: This isn't super different from the token management URIs, but the RS has no way to get that URI, and it's bound to the RS's keys instead of the RC's or token's keys.
From a privacy point of view, token introspection allows an AS to know exactly when operation(s) are being performed by an end-user on a RS. This provides useful information for ASs that may be tempted to act as "Big Brother". For that reason, the risks related to token introspection should be advertised in the Privacy Considerations section. Its usage should be deprecated in the general case. If there exists specific cases where there is no such a risk, these cases should be advertised.
The section doesn't provide any information on what happens when a client wants to introspect an inactive/invalid/revoked token.
Yes, this is pretty thin right now. It's the RS that introspects the token, and this section will be pulled out into a separate spec to make that more clear (). The response for both positive and negative situations is likely to be based on the OAuth introspection spec, RFC7662 URL
We should add: the AS MUST validate that the token is appropriate for the RS that presented it, and return an error otherwise.
In OAuth token introspection, the AS doesn't return an error in this stated case -- it simply says the token presented is not active, in order to prevent information leakage to a nosy RS.
NAME I don't understand your argument about a "nosy RS". The text states: As a consequence, if the AS does not recognize the signature, it can return a error stating "bad signature". If the signature is correct, the AS can provide all details to the recognized RS, as yaronf mentioned.
s/error/inactive status/.
Token Introspection: it is not clear to what depth we are defining the API: is it only the existence of the "introspect" endpoint? Or do we define a minimal set of standard attributes that need to be returned? The API would not be useful for interoperability unless we define some of the returned attributes. At the very least: "active".
The idea would be to define a core attribute set with extension points like RFC7662. This same attribute set could be used for the token model (but maybe not format?) described in

The RS signs the request with its own key and sends the access token as the body of the request. <ins> REQUIRED.  The access token value presented to the RS by the client instance. RECOMMENDED.  The proofing method used by the client instance to bind the token to the RS request. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The minimum access rights required to fulfill the request.  This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol. The AS MUST validate the access token value and determine if the token is active.  An active access token is defined as a token that was issued by the processing AS, has not been revoked, has not expired, and is appropriate for presentation at the identified RS. </ins> The AS responds with a data structure describing the token's current state and any information the RS would need to validate the token's presentation, such as its intended proofing mechanism and key  <ins> material. REQUIRED.  If "true", the access token presented is active, as defined above.  If any of the criteria for an active token are not true, or if the AS is unable to make a determination (such as the token is not found), the value is set to "false" and other fields are omitted. If the access token is active, additional fields from the single access token response structure defined in I-D.ietf-gnap-core- protocol are included.  In particular, these include the following: REQUIRED.  The access rights associated with this access token. This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol.  This array MAY be filtered or otherwise limited for consumption by the identified RS, including being an empty array. REQUIRED if the token is bound.  The key bound to the access token, to allow the RS to validate the signature of the request from the client instance.  If the access token is a bearer token, this MUST NOT be included. OPTIONAL.  The set of flags associated with the access token. The response MAY include any additional fields defined in an access token response and MUST NOT include the access token "value" itself. </ins> 3.4.