Hi Brian,
here are my text proposals (and a comments):
- Section 2, resource parameter definition
„It MUST be an absolute URI, as specified by Section 4.3 of[RFC3986],
and MUST NOT include a query or fragment component.“
Why does the draft preclude query components?
- I would propose to add the following text at the end of Section 2 (before the
last paragraph):
"The authorization server SHOULD adapt the scope value associated
with an access token to the value the respective resource(s) is
able to process and needs to know. This further improves privacy as
scope values give an indication of what services the resource owner
uses and it improves security as scope values may contain confidential
data. The authorization server MUST indicate the access token’s
effective scope to the client in the „scope" response value.
The authorization server MUST ensure the client is able to obtain other sub
sets of
the underlying grant or the whole scope in subsequent transactions. In case of
a confidential client, the authorization server might associate the grant with
its client_id. In case of a public client, a refresh token could be used to
represent
the grant."
I think it would make sense to establish the link to William‘s draft, as I see
common patterns re grant handling.
- I’m proposing to add the following text re resource indicators and the code
response type (potentially in a new section).
„The authorization server MAY require clients to specify the resource(s) they
intend to
access in requests to the authorization endpoint with response type „code". The
authorization server might use this data to inform the user about the resources
the client is going to access on her behalf, to meet policy decision (e.g.
refuse the
request due to unknown resources), and determine the set of
resources that can be used in subsequent access token requests.“
kind regards,
Torsten.
> Am 04.08.2018 um 05:39 schrieb internet-dra...@ietf.org:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>Title : Resource Indicators for OAuth 2.0
>Authors : Brian Campbell
> John Bradley
> Hannes Tschofenig
> Filename: draft-ietf-oauth-resource-indicators-00.txt
> Pages : 8
> Date: 2018-08-03
>
> Abstract:
> This straw-man specification defines an extension to The OAuth 2.0
> Authorization Framework that enables the client and authorization
> server to more explicitly to communicate about the protected
> resource(s) to be accessed.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
