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

[Roman Danyliw <[e-mail]>]

Hi Brian!

Thanks for this background and explanation.  There was history here I didn’t know.

With the benefit of this thread and private exchanges, the key takeaways for me are:

** the definition of 'resource' for 'token exchange' is identical in both drafts (draft-ietf-oauth-resource-indicator and draft-ietf-oauth-token-exchange)

** draft-ietf-oauth-resource-indicators has additional “uses” of resource not germane to draft-ietf-oauth-resource-indicator

** the desired ends-state after the IANA considerations sections of both drafts were process, the Oauth registry would look as follows:
- name = resource
- parameter usage location = authorization request, token request
- change controller = IETF
- reference = draft-ietf-oauth-resource-indicator

Is that right?

If the above is correct, would the following way ahead work:

** for draft-ietf-oauth-token exchange: Nothing

** for draft-ietf-oauth-resource-indicator

Per Section 4.1:

   This specification updates the following value in the IANA "OAuth
   Parameters" registry [IANA.OAuth.Parameters] established by
   [RFC6749].

   o  Parameter name: resource
   o  Parameter usage location: authorization request, token request
   o  Change controller: IESG
   o  Specification document(s): [[ this specification ]]

Per Section 4.2
   This specification updates the following error in the IANA "OAuth
   Extensions Error Registry" [IANA.OAuth.Parameters] established by
   [RFC6749].

   o  Error name: invalid_target
   o  Error usage location: implicit grant error response, token error
      response
   o  Related protocol extension: resource parameter
   o  Change controller: IESG
   o  Specification document(s): [[ this specification ]]

Roman


From: Brian Campbell [mailto:[e-mail]]
Sent: Wednesday, July 17, 2019 6:31 PM
To: Roman Danyliw <[e-mail]>
Cc: [e-mail]
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Yeah, as you surmised, there is some history behind this. Basically draft-ietf-oauth-token-exchange predates draft-ietf-oauth-resource-indicators by a good long time (years) and with the hope and expectation that draft-ietf-oauth-token-exchange would move to RFC, I've avoided having a reference in it to a draft much earlier along in the whole process. draft-ietf-oauth-resource-indicators has a bit of an odd history too in that an initial call for adoption around the Buenos Aires meeting kinda fizzled out and it was left for dead until being unexpected resurrected around Montreal last year due to renewed interest and other factors I'm still not sure I understand.

You are correct that draft-ietf-oauth-token-exchange defines "resource" for token exchange. However the registry itself doesn't have that level of granularity. It has authorization request, authorization response, token request, and token response as the possible locations for parameter usage. A token exchange request is a particular kind of token request so draft-ietf-oauth-token-exchange registers "resource" for the token request location. The IANA section was written before draft-ietf-oauth-resource-indicators even existed. And leaving the registration in draft-ietf-oauth-token-exchange seemed like the right thing to do to even after draft-ietf-oauth-resource-indicators came along. But I'm not sure, to be honest. Also FWIW a temporary registration entry for it is already in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

draft-ietf-oauth-resource-indicators defines "resource" for use at the authorization endpoint (which token exchange does not) so that's the impetus behind having the registration request there include authorization request in the location. draft-ietf-oauth-resource-indicators also has "resource" for use at the token endpoint using the same semantics as in draft-ietf-oauth-token-exchange but in a way that is applicable to all types of token requests to the the token endpoint and not only token exchange requests. That's where the idea of updating the registry came from - it's not a name collision and it's not a different definition - it's just a more generalized usage.

I hope this makes some sense and hasn't muddied the waters more.



On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[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?

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.