Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify use of response parameters in RS-first discovery #527

Merged
merged 2 commits into from
Feb 10, 2024
Merged

Clarify use of response parameters in RS-first discovery #527

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a545a82
Clarify use of response parameters in RS-first discovery
jricher Feb 7, 2024
e9fc8f4
add reference and move condition
jricher Feb 8, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 15 additions & 2 deletions draft-ietf-gnap-core-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5319,10 +5319,23 @@ Additional fields can be defined the [GNAP Authorization Server Discovery Fields

## RS-first Method of AS Discovery {#rs-request-without-token}

If the client instance calls an RS without an access token, or with an invalid access token, the RS SHOULD be explicit about the fact that GNAP needs to be used to access the resource, by responding with the WWW-Authenticate header field and a GNAP challenge.
If the client instance calls an RS without an access token, or with an invalid access token, the RS SHOULD be explicit about the fact that GNAP needs to be used to access the resource by responding with the WWW-Authenticate header field and a GNAP challenge.

In some situations, the client instance might want to know with which specific AS it needs to negotiate for access to that RS.
The RS MAY additionally return the address of the GNAP endpoint in the `as_uri` parameter, a `referrer` parameter to indicate which RS initiated the discovery process, and an opaque `access` reference. The client instance SHOULD then use both the `referrer` and `access` parameters in its access token request. The `referrer` parameter MUST be the URI of the RS, and the client instance MUST check its value to protect itself. The opaque `access` reference MUST be sufficient for at least the action the client instance was attempting to take at the RS and MAY allow additional access rights as well.
The RS MAY additionally return the following OPTIONAL parameters:

`as_uri`:
: The URI of the grant endpoint of the GNAP AS. Used by the client instance to call the AS to request an access token.

`referrer`:
: The URI of the GNAP RS. Sent by the client instance in the Referer header as part of the grant request.

`access`:
: An opaque access reference as defined in {{resource-access-reference}}.
MUST be sufficient for at least the action the client instance was attempting to take at the RS and MAY allow additional access rights as well.
Sent by the client as an access right in the grant request.

The client instance SHOULD then use both the `referrer` and `access` parameters in its access token request. The client instance MUST check that the `referrer` parameter is equal to the URI of the RS using the simple string comparison method in {{Section 6.2.1 of RFC3986}}.

The means for the RS to determine the value for the `access` reference are out of scope of this specification, but some dynamic methods are discussed in
{{I-D.ietf-gnap-resource-servers}}.
Expand Down
Loading