Hi!
I forgot one more thing about this draft after re-reading
draft-ietf-oauth-token-exchange.
Per the IANA action in Section 4.1, I need help understanding on the thinking
to resolve this TODO:
o Parameter usage location: authorization request, token request
[[TODO: draft-ietf-oauth-token-exchange will have already
registered this for 'token request' and this draft has a more
generalized usage and needs to somehow either update that
registration or do a partial registration and reference]]
o Change controller: IESG
o Specification document(s): [[ this specification ]]
My read of draft-ietf-oauth-token-exchange it that it defines 'resource' for
'token exchange'. This draft (draft-ietf-oauth-resource-indicators) has
guidance on 'resource' for 'authorization request' but also additional guidance
for 'token request'. Is the token guidance request stated here applicable to
draft-ietf-oauth-token-exchange too (i.e., is the text effectively saying
oauth-resource-indicators updates oauth-token-exhange)? I ask because these
drafts don't reference each other.
Correct me because there is likely a history, but it seems the TODO is that
there is a dependency to resolve and a need to coming up with a way to signal
in the registry which draft should be read for what usage location. Could
draft-ietf-oauth-resource-indicators officially register 'resource'; and
instead of draft-ietf-oauth-token-exchange including the text defining
'resource' in Section 2.1, it would make a normative reference to Section 2 of
draft-ietf-oauth-resource-indicators?
Roman
> -----Original Message-----
> From: Roman Danyliw
> Sent: Tuesday, July 16, 2019 7:23 PM
> To: oauth@ietf.org
> Subject: AD Review: draft-ietf-oauth-resource-indicators-02
>
> Hi!
>
> The following is my AD review of draft-ietf-oauth-resource-indicators-02.
> The document is in good shape.
>
> (1) Section 2. Per "The parameter can carry the location of a protected
> resource, typically as an https URL, or a more abstract identifier", is this
> "abstract identifier" still an absolute URI per Section 4.3 of RFC3986?
>
> (2) Section 2.2. in the sentence "To the extent possible, when issuing access
> tokens, the authorization server should adapt the scope value associated
> with an access token to the value the respective resource is able to process
> and needs to know":
>
> -- is this language suggesting that the authorization server is modifying the
> scope value based on the resource it sees? I'm trying to understand what
> "adapt" means, especially in relation to the improved security and privacy the
> subsequent sentence suggests.
>
> -- (Depending on the above) Is there a security consideration here for the
> server relative to confidential scope values and how they might be modified?
>
> (3) Editorial
> ** Section 1 and 2.1. Multiple Typo. s/the the/the/g
>
> ** Section 2. Editorial. s/resource at which/resource to which/
>
> ** Section 2. Editorial.
> s/ And can also be used to inform the client that it has requested an invalid
> combination of resource and scope./ It can also be used to inform the client
> that it has requested an invalid combination of resource and scope./
>
> ** Section 2.1. Multiple Typo. s/an an/an/g
>
> ** Section 2.2. Editorial. s/token request and response/token request
> (Figure 3) and response (Figure 4)/
>
> ** Section 3. Typo. s/a invalid/an invalid/
>
> ** Section 3. Missing words. "A bearer token that has multiple intended
> recipients (audiences) can be used by any one of those recipients at any
> other." Is it protected resource?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
