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=40pingidentity....@dmarc.ietf.org
<mailto:40pingidentity....@dmarc.ietf.org>> 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
<da...@alkaline-solutions.com
<mailto:da...@alkaline-solutions.com>> 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=40aol....@dmarc.ietf.org
<mailto:gffletch=40aol....@dmarc.ietf.org>> 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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
