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:bcampb...@pingidentity.com]
Sent: Wednesday, July 17, 2019 6:31 PM
To: Roman Danyliw <r...@cert.org>
Cc: oauth@ietf.org
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
<r...@cert.org<mailto:r...@cert.org>> 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: oauth@ietf.org<mailto: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<mailto:OAuth@ietf.org>
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
