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

oth are valid > >>>>> > >>>>> Hans. > >>>>> > >>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones < > michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com> michael.jo...@microsoft.com> <mailto:michael.jo

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

gt;>>> <mailto:40auth0@dmarc.ietf.org> <mailto:40auth0@dmarc.ietf.org>>; >>>>> IETF oauth WG mailto:oauth@ietf.org> >>>>> <mailto:oauth@ietf.org> <mailto:oauth@ietf.org>> >>>>> Subject: Re: [OAUTH-WG]

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

Fletcher mailto:40aol@dmarc...ietf.org>>; Vittorio Bertocci mailto:40auth0....@dmarc.ietf.org>>; IETF oauth WG mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 the definition of RFC 7519 is actually "petitio principii&qu

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

gt;>>>> Note, John Bradley observed that in some cases this might lead to >>>>> ambiguous results if an extension grant is used (say an assertion >>>>> profile) but that seems like a relatively fringe occurrence. >>>>> >>>>> On Th

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

>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones >>> <mailto:michael.jo...@microsoft.com> <mailto:michael.jo...@microsoft.com> >>>> <mailto:michael.jo...@microsoft.com>> wrote: >>>> I get that existing practice is likely to be all o

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

t’s reasonable to require that the >> claims usage comply with the JWT standards. >> >> >> >> -- Mike >> >> >> >> From: Hans Zandbelt > <mailto:hans.zandb...@zmartzon

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

On 07/05/2019 11:48, Vittorio Bertocci wrote: > name > TBD given that sub_type is taken already Meaning that it cannot be used in a AT as JWT? What spec is that? Thanks, Vladimir -- Vladimir Dzhuvinov ___ OAuth mailing list OAuth@ietf.org https://w

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

e valid >>> >>> Hans. >>> >>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones >> <mailto:michael.jo...@microsoft.com>> wrote: >>> I get that existing practice is likely to be all over the map, but if we’re >>> to create a JWT access token s

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

out the resource owner, >>> hence both are valid >>> >>> Hans. >>> >>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones >>> wrote: >>> >>>> I get that existing practice is likely to be all over the map, but if >>>> we’

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

t.com>> wrote: >> I get that existing practice is likely to be all over the map, but if we’re >> to create a JWT access token standard, it’s reasonable to require that the >> claims usage comply with the JWT standards. >> >> >> >>

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

t; >>> >>> -- Mike >>> >>> >>> >>> *From:* Hans Zandbelt >>> *Sent:* Thursday, April 4, 2019 12:59 PM >>> *To:* Mike Jones >>> *Cc:* George Fletcher >

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

tzone.eu>> > Sent: Thursday, April 4, 2019 12:59 PM > To: Mike Jones <mailto:michael.jo...@microsoft.com>> > Cc: George Fletcher <mailto:40aol@dmarc...ietf.org>>; Vittorio Bertocci > mailto:40auth0@dmarc.ietf.org>>; > IETF oauth WG mailto:oauth@ietf

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

It looks like we'll have to agree to disagree on this one :) to me we aren't using 3 claims to say that the token is about the client. Sub and client_id have their independent reasons to be in the token. Expressing the fact that a token is about an app should not have the side effect of forbidding

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

using 2 existing + 1 new (=3) claims to say the token is about the client to me suggests something went sideways in the past and were unable to fix it in a clean way Hans. On Tue, May 7, 2019 at 8:25 AM Vittorio Bertocci wrote: > For many of the products I have been and I am working on, sub and

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

For many of the products I have been and I am working on, sub and client_id can't be arbitrarily changed - the examples I provided aren't hypothetical: in my research *all *the providers adding sub in their app only ATs (Azure AD, Auth0, Ping Identity) had different values in sub and in the claim t

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

I understand your legacy-breaking point (and do see a name spacing hurdle) but: a. I feel we're now painting ourselves into a corner ("soft doctors make stinking wounds"). b. putting the client_id into the sub value would be something that any product should be able to do, just like putting an extr

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

Let me try a different angle. An AS might generate sub claims and client_id identifiers using a different format/template. That means that there might be a client with client_id X that gets assigned a sub value Y, despite the client being the same, hence the check “sub==client_id” would fail. The l

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

I'm suggesting that whichever "sub" and "client_id" the RS is receiving and however it was generated, it must mean something to it in alignment with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; moreover, if the "sub" has the same value as "client_id" it must be a client talking

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

I am not following. We want this to be adopted, right? :) if we provide guidance that is sound but hard to implement we are going to fail. Considerations on whether the guidance requires a big effort to be applied are very much in scope for me. On Mon, May 6, 2019 at 14:54 Hans Zandbelt wrote: >

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

the scope and way of generating sub/client_id is orthogonal to the semantics IMHO but if I'm the only one who thinks so, I'll rest my case Hans. On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci wrote: > See below, Hans- the sub doesn’t have to be global, it could be something > generated just

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

See below, Hans- the sub doesn’t have to be global, it could be something generated just for this particular RS. Or the AS might have its own recipe for generating sub values that different from the recipe used to generate client_ids. It would be much easier for an AS to emit a claim making this ex

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

I may be missing something but I'd argue that by requiring and comparing both "sub" and "client_id" we achieve the same semantics without a new/additional claim (barring name spacing) Hans. On Mon, May 6, 2019 at 8:58 PM Karl McGuinness wrote: > Makes sense that we don’t want to further couple

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

In OpenID Connect, aggregated and distributed claims are ways for the OpenID Provider to reference claims issued by other entities (e.g. attribute provider or "Issuer" in the SSI sense). There is no requirement from a spec perspective that the /userinfo endpoint be co-located with the AS. It se

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

Makes sense that we don’t want to further couple AS and RS with grant types. I’m OK if we want a dedicated claim to establish whether the token is resource owner delegated vs client acting as itself. Subject Type is already a concept in RISC. Just making folks are aware of prior art. https:

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

On 06/05/2019 22:26, Vittorio Bertocci wrote: > I am not following, Vladimir. What do you mean? Can you make some examples > to clarify? > The userinfo is always colocated with the AS, hence I would expect most > vendors not to use JWT for the ATs issued for userinfo access That's what I was curio

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

Fair enough! What others think about it? Exploring the approach: would we want a bool claim or an enumeration, e.g. sub_type = [ resource_owner | client ] ? On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov wrote: > Hi Vittorio, > > On 06/05/2019 22:22, Vittorio Bertocci wrote: > > It is true

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

Hi Vittorio, On 06/05/2019 22:22, Vittorio Bertocci wrote: > It is true that the grant_type is a client side consideration. I did think > about the "client_id==sub" heuristic, but that's not always applicable: > many systems have their own rules for generating sub, and in case they want > to preve

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

It is true that the grant_type is a client side consideration. I did think about the "client_id==sub" heuristic, but that's not always applicable: many systems have their own rules for generating sub, and in case they want to prevent tracking across RSes the sub might be generated ad-hoc for that p

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

I am not following, Vladimir. What do you mean? Can you make some examples to clarify? The userinfo is always colocated with the AS, hence I would expect most vendors not to use JWT for the ATs issued for userinfo access On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov wrote: > > https://tools

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

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2 In OpenID Connect the access token is consumed by the UserInfo endpoint. Were there any suggestions to also spec parameter(s) for the claims names (with optional locales) for release at the UserInfo endpoint? Vladimir

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

On 06/05/2019 20:32, Vittorio Bertocci wrote: > To that end, *Karl MCGuinness suggested that we include > grant_type as a return claim, which the RS could use to the same effect*. I > find the proposal very clever, and the people at IIW thought so as well. > What you think? The grant type is not s

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

> >> >> -- Mike >> >> >> >> *From:* Hans Zandbelt >> *Sent:* Thursday, April 4, 2019 12:59 PM >> *To:* Mike Jones >> *Cc:* George Fletcher > <40aol....@dmarc..ietf.org>>; V

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

"quotes my own articles on the matter extensively" - I know and almost mentioned that but didn't want to further embolden your ego :) Silence is rarely assent. Especially near the end of the last session of the last day of a workshop. And when I've got a train to catch. I am somewhat sympathetic

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

Fra: OAuth På vegne av Dave Tonge Sendt: tirsdag 26. mars 2019 09.27 Til: Dominick Baier Kopi: IETF oauth WG Emne: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thanks Vittorio for your presentation and putting this draft together. I agree with Dominck that there is a potential of

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

April 4, 2019 12:59 PM > *To:* Mike Jones > *Cc:* George Fletcher ; Vittorio > Bertocci ; IETF oauth WG < > oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > > > > the definition of RFC 7519 is actually "petitio principi

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

: Thursday, April 4, 2019 12:59 PM To: Mike Jones Cc: George Fletcher ; Vittorio Bertocci ; IETF oauth WG Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 the definition of RFC 7519 is actually "petitio principii" and a lot of deployments put claims about the Resource Ow

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

eorge Fletcher > *Sent:* Thursday, April 4, 2019 8:51 AM > *To:* Hans Zandbelt > *Cc:* Vittorio Bertocci ; IETF oauth > WG > *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > > > > The more I think about this the more I land in the "No" camp.

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

: Vittorio Bertocci ; IETF oauth WG Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 The more I think about this the more I land in the "No" camp. The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a use

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

I get your 1st party use case and if you think about a company that might have multiple endpoints on different domains that provide API services all invoked by a mobile app... requiring the mobile app to effectively downscope (or resource indicator bind) tokens means a lot of chatter between th

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

Thanks Martin. Inline I kind of agree that you might want to have this information in the token, > if possible. You can save a lot of round trips over time (at the expense of > revocation). Yep, this entire profile idea emerged as acknowledgement that a large number of services and products choos

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

> > As an aside, I worry about trying to put all information needed to make a > dynamic policy decision into an access token. I am not suggesting any of this would be exhaustive. The intent is to give guidance on the most commonly used elements, stuff we already know is being considered. Besides a

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

Hi Vittorio, > On 4. Apr 2019, at 19:19, Vittorio Bertocci > wrote: > > But before I get in the details, let me make an uber-point.. > I am acutely aware of the potential for confusion and abuse in the context of > OAuth and sign in, the article you pointed to quotes my own articles on the >

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

Hey George! Thanks for the comments. nline The issue here is that the 'aud' of the id_token is the recipient of the > id_token (i.e. the client). However, for access_tokens the 'aud' value > should be the resource service that will receive the access_token. There is > no existing guidance for this

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

But before I get in the details, let me make an uber-point. I am acutely aware of the potential for confusion and abuse in the context of OAuth and sign in, the article you pointed to quotes my own articles on the matter extensively. But there are concrete aspects that need to be considered about w

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

I agree. Maybe RFC 7519 is actually as good as it gets wrt claim specifications? At least for OAuth. Use case specific profiles can/must then use their own definitions (see OIDC) for (JWT) ATs. I mean, at least for OIDC, an AT which is the result of a client credential grant isn't even a thing wh

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

A few remarks/responses inline below this time... On Wed, Apr 3, 2019 at 1: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 c

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

I believe the root problem is that we're trying to unify across tokens that are issued for different use cases (auth vs. authz), different subjects and different audiences. The JWT spec allows us to cover those use cases nicely within its own semantics but the profile specific use case semantics ar

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

I think what needs to be clarified is whether the "sub" claim should denote the caller (=client) or the RO in the case of an JWT AT. RFC 7519 only defines "sub" to be the principal which is the subject of all claims in the JWT. This means that the AT can contain either claims regarding the client

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

The more I think about this the more I land in the "No" camp. The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need

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

I'm not sure I understand what you mean but this document would reference the RFC 7519 claims and, if needed, futher profile their usage for access tokens. On Thu, Apr 4, 2019 at 9:39 AM Hans Zandbelt wrote: > agreed but it (i.e. "sub") also brings us back to where we started > > Hans. > > On Th

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

:) The more I think about 'sub' the more I don't think is should mean "user". What about an IoT device? To me it feels like 'sub' should be what 7519 states, the subject or principal of the token. In some cases, that is quite legitimately the "client" or "machine". Changing that semantic seem

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

agreed but it (i.e. "sub") also brings us back to where we started Hans. On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell wrote: > The same is true for most of the other main claims too - iss, exp, aud, > sub, iat, etc.. They are defined in RFC 7519 not OIDC. > > On Thu, Apr 4, 2019 at 9:21 AM Bri

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

The same is true for most of the other main claims too - iss, exp, aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC. On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell wrote: > Yeah, OpenID.Core isn't the right reference for `aud`. > https://tools.ietf.org/html/rfc7519#section-4.1.3 is the

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

Yeah, OpenID.Core isn't the right reference for `aud`. https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of `aud` which should be the reference and this document can provide additional specifics for the given application. On Thu, Apr 4, 2019 at 8:07 AM George Fletcher wrote: >

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

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

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

Another comment... aud REQUIRED - as defined in section 2 of [OpenID.Core ]. See Section 3 for indications on ho

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

My experience: When building modern applications, we use OIDC and OAuth together for authentication, session management and API access. Only the combination makes sense (to me) here. Hence it also makes sense (for me) to share claims types going forward. IdentityServer is a framework that is typi

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

I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.. Hans. On Wed, Apr 3, 2019 at 10:48 PM George Fletcher wrote: > I agree that this wi

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

I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :) On 3/26/19 12:56 PM, Hans Zandbelt wrote: great summary! this will hurt quite a few existing m2m deployments but I do like th

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

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. However I think it's important th

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

+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

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

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

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

Thanks for writing this up. One comment on auth_time... auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. Important: as this claim represents the time at which the end user authen

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

Hey Benjamin, Of course I agree that sheer headcount isn’t the main factor :). The main point here is that this is a profile meant to promote and facilitate interoperability, so _as long as a proposal is is sound & secure_, the number of products and services favoring it does have direct impact on

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

Hi Vittorio, On Tue, Mar 26, 2019 at 09:48:08AM -0700, Vittorio Bertocci wrote: > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. Martin would like to have the > su

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

Fra: OAuth På vegne av Dave Tonge Sendt: tirsdag 26. mars 2019 09.27 Til: Dominick Baier Kopi: IETF oauth WG Emne: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thanks Vittorio for your presentation and putting this draft together. I agree with Dominck that there is a potential of

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

Thank you, Martin! RFC7523 was the reason for which i had the sub in the first JWT AT profile draft the way I did. The proposal of requiring it only for user flows and disallowing it otherwise is not in alignment with RFC7523, which does not sound like a good thing, but ultimately the function of J

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

Hi Dave, either a type check or a lookup for client_id together with absence of sub are going to be new logic- the latter seems to be more economical in term of moving parts, without loss of expressive power. I am not really committed to one model or the other, I just want to capture the approach t

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

> On 26. Mar 2019, at 17:48, Vittorio Bertocci > wrote: > > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. Martin would like to have the > sub for app only f

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

great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board Hans. On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci wrote: >

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

Hi Vittorio My understanding from Rob and others is that `sub` is already used for tokens issued via the client credentials grant (in fact looking at the tables from your presentation, most examples used `sub` for both user identity and client identity). Given the desire for a spec that doesn't br

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

thank you Steinar and everyone else for the comments on this! To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral. That does sound like the sub as user has m

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

Hi Vittorio, we (the national federation-gateway for the health services in norway - "HelseID") think his is a really valuable initiative! We also agree with Dominick concerning definition of the "sub" claim. Steinar tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier : > From an access token co

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

I’d like to add my support for not proposing any change to how sub is typically interpreted for client credentials tokens. In my experience the usage of the client_id as the subject in this flow is well established and it would cause disruption to many current implementations should that be change

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

Thanks Vittorio for your presentation and putting this draft together. I agree with Dominck that there is a potential of things going wrong when `sub` has multiple meanings. However I can see that using `sub` for a client_id semantically makes sense in some situations and I agree that it makes it

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

Hi, first time posting here but I have a comment on the "sub" claim: We use RFC7523 for client authentication in a machine to machine scenario (i.e. client credentials grant). In this RFC, the JWT used as client assertion is defined that it "MUST contain a "sub" (subject) claim identifying the

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

>From an access token consumer (aka API) developer point of view, I prefer this logic "If sub is present - client acts on behalf of a user, if not - not." Anything more complicated has a potential of going wrong. On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com) wrote: Hi Vittorio,

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

Hi Vittorio, Yeah, I’m concerning user & client ids collision. I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide. If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I

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

d.cof...@reminetworks.com > > > > *From:* Dominick Baier > *Sent:* March 25, 2019 10:39 AM > *To:* Hans Zandbelt > *Cc:* IETF oauth WG ; Nov Matake ; > vitto...@auth0.com > *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > > > > Yes I know

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

or the token format? I > see that the "nbf" (not before) claim is defined there > > Regards, > -- > > *Bertrand CARLIER * > > *From:* OAuth *On Behalf Of *Vittorio Bertocci > *Sent:* lundi 25 mars 2019 00:29 > *To:* IETF oauth WG > *Subject:* [OAUTH-WG]

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

Hey Nov, Dominick, Hans- thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify. The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However

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

Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com <mailto:donald.cof...@reminetworks.com> From: Dominick Baier Sent: March 25, 2019 10:39 AM To: Hans Zandbelt Cc: IETF oauth WG ; Nov Matake ; vitto...@auth0.com Subject: Re: [OAUTH-WG] draft-bertocci-oauth-

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

I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same). Hans. On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier wrote: > Yes I know - an

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

ely on RFC 7662 (Introspection) for the token format? I see that the "nbf" (not before) claim is defined there Regards, -- Bertrand CARLIER From: OAuth On Behalf Of Vittorio Bertocci Sent: lundi 25 mars 2019 00:29 To: IETF oauth WG Subject: [OAUTH-WG] draft-bertocci-oauth-access-tok

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

Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics. All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always c

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

Nice work Vittorio. I think the "sub" claim can also be used to reference the client (depending on the implementation may not necessarily map to the client_id). It might eventually reference the same entity as the client_id. In addition to the "sub" claim, does it make sense to explicitly have th

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

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token. The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: "The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JW

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

IMHO the sub claim should always refer to the user - and nothing else. OIDC says: "Subject - Identifier for the End-User at the Issuer." client_id should be used to identify clients. cheers Dominick On 25. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote: Hi Vittorio, Thanks for t

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

Hi Vittorio, Thanks for the good starting point of standardizing JWT-ized AT. One feedback. The “sub” claim can include 2 types of identifier, end-user and client, in this spec. It requires those 2 types of identifiers to be unique each other in the IdP context. I prefer omitting “sub” claim

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

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! H