Re: [OAUTH-WG] MTLS and SAN

Yes. S pozdravem, *Filip Skokan* On Thu, 4 Apr 2019 at 22:36, Justin Richer wrote: > Thank you, I did miss that text. This should be called out more explicitly > in §2.1, perhaps by specifying that it is only one field. This still > doesn’t set precedence, but it implies that it’s an error for

Re: [OAUTH-WG] MTLS and SAN

Thank you, I did miss that text. This should be called out more explicitly in §2.1, perhaps by specifying that it is only one field. This still doesn’t set precedence, but it implies that it’s an error for a client to have more than one field set of the available options. Is that your read on th

Re: [OAUTH-WG] MTLS and SAN

Justin, I had the exact same question off list and believe draft 13 clarified this. https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2 A client using the "tls_client_auth" authentication method MUST use exactly one of the below metadata parameters to indicate the certificate subje

[OAUTH-WG] MTLS and SAN

We’ve just started implementation of SAN-based certificate authentication, based on the changes in version -13 of the draft. I believe this addition is a bit unclear, due to it being added so late in the document process. My question is how does an AS determine whether to DN or SAN for certifica

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

I also meant to say that (of course) the JWT standard doesn't say that the JWT is supposed to be about the client or about 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 > w

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

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. -- Mike From: Hans Zandbelt Sent: T

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 Owner in the access token (as a Resource Server implementer I've suffered a lot from this) Hans. On Thu, Apr 4, 2019 at 9:48 PM Mike Jones wrote: > I agree with George that the subj

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

I agree with George that the subject of a token must be the principal of that token. That what the JWT “sub” claim is for. Indeed, the first sentence of the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is: The "sub" (subject) claim identifies the principal that is the s

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] Early IANA registration for Token Exchange Draft

The request originated from Ben Kaduk's Discuss ballot on the draft and suggestion that the URI values be registered. Some of the relevant messages in the thread: https://mailarchive.ietf.org/arch/msg/oauth/QiA5PDBsKlApNZIRy3QOttd-JDM https://mailarchive.ietf.org/arch/msg/oauth/E2eOLE576c_Zw6MK0ys

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