Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

[Roman Danyliw <[e-mail]>]

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: [e-mail]
> 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?