Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher <[e-mail]>]

Comments inline...

On 4/3/19 3:38 PM, Vittorio Bertocci wrote:
> Thanks guys for the comment, sorry for the delay in addressing them.
> I am not married to the claim types used in here, so if you think that 
> reusing the ones in the id_token can cause confusion we should expand 
> on the specific ways in which you think might go south.
I'm fine with re-using claims... we just need to make sure if we reuse a 
claim it keeps the same semantic.
> However I think it's important that the information on say, whether 
> the current token was obtained using MFA or a specific authentication 
> factor is something that API developers can legitimately latch to when 
> doing authorization decisions. From the perspective of a developer 
> modeling a solution, whether functionality is delivered as a route in 
> a postback based web app (hence receiving an id_token or derived) or 
> as an API consumed by a native app, the business requirement gating 
> access to that functionality doesn't change. If the admin managing 
> that resource establishes that access should be performed only via 
> MFA, the developer should be equipped to enforce that regardless of 
> the stack used to expose functionality (web app, API).
> Although it is true that triggering the desired behavior might be 
> achieved by the resource setting and contract with the AS, along the 
> lines of what David said, it's actually not uncommon for those 
> policies to be assigned on the resource AFTER the current session was 
> established and/or the corresponding AT was obtained and cached. 
> Furthermore, the requirement might be more granular than an AS policy 
> can tolerate (an API might requires MFA only for certain routes, hence 
> hard to express in a static policy) and triggered in form of 
> challenges. So the situation in which you have an AT with the right 
> issuer, audience, etc but was obtained with a policy now 
> obsolete/unacceptable to the RP is strong. Requesting to support 
> revocation just for this seems overkill, especially given that the 
> scenario in which the same logical app is exposed as both web app and 
> native client+API, the code consuming those claims is already in 
> place. It just makes intuitive sense for developers.
> In summary, one can take steps to push as much of the MFA requirements 
> to the AS settings for a particular request, but ultimately the desire 
> of the API developer to enforce that it actually happened is a 
> requirement I encountered often in practice. Anything providing extra 
> context to refine decisions about it (like auth_time, which might 
> inform decisions about whether to accept an MFA check occurred N 
> minutes ago or refuse access).
As an aside, I worry about trying to put all information needed to make 
a dynamic policy decision into an access token. For cases where the 
policy can change over time including the lifetime of the access_token 
then I prefer the User Managed Access (UMA) approach as it inherently 
allows for dynamic policy change.
>
> I thought that reusing the existing names for the same concepts just 
> made sense (dev existing skills, existing codebases, etc etc) and 
> especially in the case in which the values are exactly the same, and 
> the idea seemed to receive good support during OSW. But I am 
> completely open to change it of course, especially for cases like the 
> one identified by George.
> WDYT?
>
> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell 
> <bcampbell=[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     +1 to David's question here. I'd like to see justifying use cases
>     (beyond just the fact that some people are already doing it) for
>     auth_time, acr, and amr to be available in OAuth JWT access
>     tokens. Those claims are defined for, and in the context of, an ID
>     Token and I fear that codifying their use in an access token will
>     lead to misuse and/or confusion.
>
>     On Mon, Apr 1, 2019 at 1:03 PM David Waite
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         Do we know if there is a justifying use case for auth_time,
>         acr, and amr to be available in OAuth JWT access tokens? These
>         are meant to be messages about the client, either directly (in
>         the case of client credentials) or about its delegated
>         authorization of the user.
>
>         Embedding attributes about the user (such as group membership
>         and roles) can be used for the resource to make finer-grained
>         decisions than scopes, but normally I would expect say acr
>         limitations enforced by a resource to instead be controlled by
>         the AS requiring a higher quality authentication to release
>         certain scopes.
>
>         Thats of course not to say extensions to OAuth such as OIDC
>         can’t provide these values, just that they might better be
>         defined by those extensions.
>
>         -DW
>
>>         On Apr 1, 2019, at 9:12 AM, George Fletcher
>>         <gffletch=[e-mail]
>>         <mailto:gffletch=[e-mail]>> wrote:
>>
>>         Thanks for writing this up. One comment on auth_time...
>>
>>             auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core  <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>>                Important: as this claim represents the time at which the end user
>>                authenticated, its value will remain the same for all the JWT
>>                access tokens issued within that session.  For example: all the
>>                JWT access tokens obtained with a given refresh token will all
>>                have the same value of auth_time, corresponding to the instant in
>>                which the user first authenticated to obtain the refresh token.
>>
>>         During a current session a user can be challenged for
>>         additional credentials or required to re-authenticate due to
>>         a number of different reasons. For example, OIDC prompt=login
>>         or max_age=NNN. In this context, I'd assume that the
>>         auth_time value should be updated to the latest time at which
>>         the user authenticated.
>>
>>         If we need a timestamp for when the "session" started, then
>>         there could be a session_start_time claim.
>>
>>         Thanks,
>>         George
>>
>>         On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>>         Dear all,
>>>         I just submitted a draft describing a JWT profile for OAuth
>>>         2.0 access tokens. You can find it in
>>>         https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>>>         I have a slot to discuss this tomorrow at IETF 104 (I'll be
>>>         presenting remotely). I look forward for your comments!
>>>
>>>         Here's just a bit of backstory, in case you are interested
>>>         in how this doc came to be. The trajectory it followed is
>>>         somewhat unusual.
>>>
>>>           * Despite OAuth2 not requiring any specific format for
>>>             ATs, through the years I have come across multiple
>>>             proprietary solution using JWT for their access token.
>>>             The intent and scenarios addressed by those solutions
>>>             are mostly the same across vendors, but the syntax and
>>>             interpretations in the implementations are different
>>>             enough to prevent developers from reusing code and
>>>             skills when moving from product to product.
>>>           * I asked several individuals from key products and
>>>             services to share with me concrete examples of their JWT
>>>             access tokens (THANK YOU Dominick Baier
>>>             (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>>             Dobalian (Microsoft), Karl Guinness (Okta) for the
>>>             tokens and explanations!).
>>>             I studied and compared all those instances, identifying
>>>             commonalities and differences.
>>>           * I put together a presentation summarizing my findings
>>>             and suggesting a rough interoperable profile (slides:
>>>             https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>>>             <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>>             ) - got early feedback from Filip Skokan on it. Thx Filip!
>>>           * The presentation was followed up by 1.5 hours of
>>>             unconference discussion, which was incredibly valuable
>>>             to get tight-loop feedback and incorporate new ideas.
>>>             John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten
>>>             Lodderstedt, Nat Sakimura, Hannes Tschofenig were all
>>>             there and contributed generously to the discussion.
>>>             Thank you!!!
>>>             Note: if you were at OSW2019, participated in the
>>>             discussion and didn't get credited in the draft, my
>>>             apologies: please send me a note and I'll make things
>>>             right at the next update.
>>>           * On my flight back I did my best to incorporate all the
>>>             ideas and feedback in a draft, which will be discussed
>>>             at IETF104 tomorrow. Rifaat, Hannes and above all Brian
>>>             were all super helpful in negotiating the mysterious
>>>             syntax of the RFC format and submission process.
>>>
>>>         I was blown away by the availability, involvement and
>>>         willingness to invest time to get things right that everyone
>>>         demonstrated in the process. This is an amazing community.
>>>         V.
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         [e-mail]  <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>
>         _______________________________________________
>         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./_______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>