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

[Brian Campbell <[e-mail]>]

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]> 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]
> > 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]
> 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._