Re: [OAUTH-WG] Token Exchange status and Resource Indicators

[Brian Campbell]

On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij 
wrote:

> [...] we are investigating 'OAuth 2.0
> Token Exchange'. [...] However, I noticed that
> draft 16 has expired on April 22, 2019. Is this specification still active?
>

Yeah, it is. A nontrivial amount of stuff came up in IESG balloting on the
document
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ballot/
and I have not been able to find the time to make all the necessary
changes. Also, resulting from that IESG balloting there was the need to
request early IANA registrations of some things, which is a whole ordeal
unto itself with timelines I cannot seem to affect much even when I have
the time to try. So it's active but just hung up for a moment at the
moment.


>
> To summarize, I have to following questions:
>  - Is the 'OAuth 2.0 Token Exchange' specification still active?
>

Yes with the caveats mentioned above. I will say that although there's a
lot of work required for the document, none of it is likely to result in
functional changes so I don't anticipate anything breaking at this point.


 - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'?
>

No, that's beyond it's current scope. And it is well past last call in the
WG. But note that a logical identifier can be used as the value of the
resource parameter.


 - Can 'OAuth 2.0 Token Exchange' be updated to build on 'Resource
> Indicators
> for OAuth 2.0' rather than redefining the same parameters?
>

Not really as a matter of timing and process. But the resource parameter
will ultimately be consistent across the two.

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

Re: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback

[Brian Campbell]

On Thu, May 2, 2019 at 12:33 AM Paul Querna  wrote:

> Overall the spec felt functional, though I think the biggest gaps for
> a deployment are with the Access Token interactions, but this makes
> sense since that seems to be addressed in the future by
> 
>

This DPoP document should aspire to provide sufficient info on access token
interactions so as not to have any dependency on
draft-ietf-oauth-access-token-jwt. And I sorta doubt that PoP style tokens
will be in scope for draft-ietf-oauth-access-token-jwt at all.

Sections 6[a] and 8[b] of DPoP aim to define access token usage. Is there
specific content that you feel is missing in the draft?

[a] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-6
[b] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-8



> Is there a use case for this being present in the DPoP-Proof JWT?  As
> I've implemented DPoP, I didn't see how it was helpful to be sent as a
> `cnf` claim of the Proof?
>

As David alluded to in his reply yesterday, this is an area that is likely
to see some changes in the next revision of the draft - like doing away
with the distinction between binding and proof, moving the proof key out of
the JWT and less inappropriate use of the `cnf` claim.

But in the -01 draft the key is included with the access token via the
`cnf` claim and you're right that it's not particularly helpful to have it
also sent with the Proof.



> Request Headers vs Parameters
> > 5.  Token Request (Binding Tokens to a Public Key)
>
> Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is
> different than most other OAuth extensions that I am familiar with.
> It is easy in the Go OAuth2 library to add URL / /body params to the
> `/token` endpoint, but it is impossible to add an HTTP Header.  Is
> there a reason that the binding can't be sent as an OAuth Parameter in
> the token request body?
>

Also as David alluded to in his reply yesterday, there's a goal to have the
proof mechanism be the same for accessing the token endpoint as when
accessing resources. And using application/x-www-form-urlencoded parameters
for resource access is problematic for a litany of reasons.



HTTP Request signing may be a quagmire that this spec wishes to avoid,
>

Very much so, yes.


[snip] I'm not sure where the spec-author team wants to take this area, but
> am interested in providing feedback.
>

Somehow cleanly allowing for it by extension would be nice from the
perspective of this document. But full treatment of HTTP signing is
explicitly a non-goal of the DPoP draft with the intent that it have only a
minimal set of stuff that's signed so as to facilitate the
proof-of-possession.


JWT as AT
> >  7.  IANA Considerations
> >
> >[[TODO: MIME type registration for at+jwt ]]
>
> Assume this will eventually be done via
> 
>

That's already where it is, no?



Thank you for the work so far, and I'm happy to provide further
> feedback as the spec evolves.
>

Thanks Paul, it's just a -01 version of an individual draft at this point
(with all the authority thereby bestowed on it
) but your
participation would certainly be appreciated as the spec evolves and if
it's something the working group decides to pick up as a working group
item.

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