Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens: IPR Confirmation

Hi Hannes, Thank you! I am not aware of any IPR related to https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/. On 9/17/20, 05:48, "Hannes Tschofenig" wrote: Hi Vittorio, I am working on the shepherd writeup for the "JSON Web Token (JWT) Profile for OAuth 2.0 Acc

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Hi Benjamin, My responses are between the lines. Hi Denis, On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote: Hi Benjamin, Responses are between the lines. On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: Hi Benjamin, On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: Sinc

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Hi Denis, On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote: > Hi Benjamin, > > Responses are between the lines. > > > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > >> Hi Benjamin, > >>> On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > Since then, I questioned myself

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

On Mon, Jun 01, 2020 at 10:06:22PM +0530, Janak Amarasena wrote: > Hi all, > > My apologies, if this was already discussed. > > In section *4*. Validating JWT Access Tokens > > it > is stated; > > The resource server M

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Hi Benjamin, Responses are between the lines. On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: Hi Benjamin, On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: Since then, I questioned myself how a client would be able to request an access token that would be *strictly compliant wit

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Hi all, My apologies, if this was already discussed. In section *4*. Validating JWT Access Tokens it is stated; The resource server MUST handle errors as described in section 3.1 of [RFC6750]

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > Hi Benjamin, > > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > >> Since then, I questioned myself how a client would be able to request an > >> access token that would be > >> *strictly compliant with this Profile*. > > I don't und

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Hi Benjamin, On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: Since then, I questioned myself how a client would be able to request an access token that would be *strictly compliant with this Profile*. I don't understand why this is an interesting question to ask. The access token and in

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > > Since then, I questioned myself how a client would be able to request an > access token that would be > *strictly compliant with this Profile*. I don't understand why this is an interesting question to ask. The access token and interpre

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Hi Vittorio, I raised the following question: In the future, if additional parameters are included in the request, will the "sub" claim necessarily be present in the access token ? The answer to this question does not seem to be present in the draft. Would you be able to provide an answe

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Denis, the change you mentioned is basically a typo, which I did fix but did not publish a new draft for- that doesn’t change the substance of the consensus (and is something that will be fixed in the subsequent phases of the process). Whether the sub should be mandatory has been discussed for two

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

The current version of this draft is "draft-ietf-oauth-access-token-jwt-07" issued on April the 27 th. This means that comments sent later on on the list have not been incorporated in this draft. In particular, this one sent on April the 28 th: *1) *The title of this spec. is: JSON Web To

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Sorry for coming late in the game, but I really think that the "sub" claim should be OPTIONAL instead of REQUIRED. We are implementing OAuth 2.0 for the Norwegian health sector, where we have several resources in production already. I don't think the "sub" claim should have different meaning depen

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

to:ve7...@ve7jtb.com] > Gesendet: Dienstag, 11. März 2014 20:49 > An: Manfred Steyer > Cc: Hannes Tschofenig; Antonio Sanso; oauth@ietf.org > Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile > > Company X will likely care about the subject being asserted by company A for > aud

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

@ietf.org Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile Company X will likely care about the subject being asserted by company A for auditing and possible revocation. It may be that the extension claim accessLevel=Accounting is sufficient to grant the access token. By Policy A could make sub

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

+1. Saving a few bytes in exchange to interoperability and security possible downgrade does not seem to be a good strategy for me. Nat 2014-03-12 7:04 GMT+09:00 Phil Hunt : > I think that's the wrong perspective. If you intend the issuer to be the > subject, you need to declare it. > > I wouldn

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

I think that's the wrong perspective. If you intend the issuer to be the subject, you need to declare it. I wouldn't worry that it duplicates issuer. The fields have different meaning. Phil @independentid www.independentid.com phil.h...@oracle.com On 2014-03-11, at 1:43 PM, Antonio Sanso wrot

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

agree, but in some cases the subject is not only same as the issuer but simply it doesn’t matter. In my example below all it matters is that the assertion signed by app1 is valid…. Continue in my probably not relevant “Google example” if I set the prn same as the issuer it would not work (kee

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

on: OAuth [mailto:oauth-boun...@ietf.org] Im Auftrag von Hannes Tschofenig > Gesendet: Dienstag, 11. März 2014 16:05 > An: Antonio Sanso > Cc: oauth@ietf.org > Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile > > Maintaining both information in the JWT is IMHO valuable since it g

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

s Tschofenig Gesendet: Dienstag, 11. März 2014 16:05 An: Antonio Sanso Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile Maintaining both information in the JWT is IMHO valuable since it gives you some information about the security properties. Needless to say that there is a su

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

The specification is intended to allow the interoperation of standard libraries. In some cases the subject and the iss may be the same, however the underlying OAuth library may be a general one and always require a subject for security processing. It is possible that all libraries could have

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Ok this is my use case: - I am John Doe and going to AS to register my app named app1 - I then either upload my public key or download a private key - at this point I am ready to build my assertion, the issuer claim is going to be app1 and should suffice. is the subject really needed in this us

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

The missing scheme especially on JWT issued by google is something I understand they are working on but need to be careful about breaking existing code, so will possibly need new endpoints that are spec compliant. While in this google case the subject and the issuer happen to be the same they

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Maintaining both information in the JWT is IMHO valuable since it gives you some information about the security properties. Needless to say that there is a substantial difference between a self-created JWT and a JWT from a third party the relying party has some confidence in. Why Google has an old

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig wrote: > Thanks for clarifying. > > I took a quick look at the Google API and it seems that in their use > case the client creates the JWT and consequently the subject and the > issue would actually be the same. I suspect that this is the reason w

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Thanks for clarifying. I took a quick look at the Google API and it seems that in their use case the client creates the JWT and consequently the subject and the issue would actually be the same. I suspect that this is the reason why they omitted the subject. Could you explain why you would like t

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

hi Hannes, I am aware of the 2 documents, I might be wrong but http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also about Authorization Grant Processing (this is the part I do use in my implementation ) and not only Client Authentication Processing. Just my 0.02 $ but this seems t

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Hi Manfred, Hi Antonio, Note that there are two documents that talk about the JWT and you guys might be looking at the wrong document. The main JWT document (see http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines the subject claim as optional (see Section 4.1.2). The JWT bear

Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Hi Antonio, some time ago, I wrote about the same issue, but – unfortunately – didn’t get an answer. I place my thoughts about this at the end of this mail. Wishes, Manfred 8<--- Hi, the draft about the JWT Profile for OAuth 2.0 Client Authent