In regards to the comment on section 4.1, it depends on the
authorization policy and the deployment architecture. I don't believe
there is a single solution that will work with all deployments.
It may be worth calling out that exposure of the entire delegation chain
can leak information and that care should be taken to ensure the entity
receiving the token with this information is in fact authorized to
receive it.
On 11/20/18 2:50 PM, Alissa Cooper wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Section 6: The requirements around confidentiality here are weaker than in both
RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Section 3:
If I understand this correctly:
"The distinction between an access token and a JWT is subtle."
I think it would be clearer if it said:
"The distinction between an access token type and a JWT token type is subtle."
Section 4.1:
What is the value of maintaining the whole delegation chain rather than
expressing just the most recent delegation? Doesn't it potentially expose
information about past exchanges unnecessarily?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
