[OAUTH-WG] SD-JWT, related work

[Nikos Fotiou]

Hi,
I am doing some research about work related to SD-JWT. I found this old
paper, which presents a solution similar to the SD-JWT disclosures

Ron Steinfeld et al. "Content Extraction Signatures", 2001 (
https://eprint.iacr.org/2002/016.pdf)

May be its formalizations and theorems are useful to this group.

I would appreciate pointers to any other related effort in similar contexts.

Best,
Nikos
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] SD-JWT, use of JSON path in disclosure claim name

[Nikos Fotiou]

I was wondering if ever occured to use a JSON path-like approach as
disclosure name. This will result in a single top level _sd key and will
remove the need for sperating discolsures that conern objects vs those that
concern arrays. If this has been disussed in the past, what are its
disadvantages? A version of example in 6.1 using this hypothetical approach
follows.

SD-JWT payload (the difference is in the "nationalities" key, the hash
values have been moved to the _sd claim . Note that the hash values are not
correct )
{
 "_sd": [
   "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
   "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
   "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
   "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
   "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
   "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
   "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
   "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4",
   "pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo",
   "7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0"
 ],
 "iss": "https://issuer.example.com;,
 "iat": 168300,
 "exp": 188300,
 "sub": "user_42",
 "nationalities": [],
 "_sd_alg": "sha-256",
 "cnf": {
   "jwk": {
 "kty": "EC",
 "crv": "P-256",
 "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
 "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
   }
 }
   }


Disclosures for nationalities
Contents: ["lklxF5jMYlGTPUovMNIvCA", $['nationalities'][0],"US"]
Contents: ["nPuoQnkRFq3BIeAm7AnXFA", $['nationalities'][1],"DE"]

Each attribute of the streat address can be easily represented as a
different disclosure
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", $['address']['region'],
"Sachsen-Anhalt"]
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", $['address']['country'], "DE"]

Best,
Nikos
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Nikos Fotiou]

Hi Kristina,

Oh yes, now "merge payload" that Daniel mentions makes much more sense. IMHO
the example in your email is better than example 4 . Two minor comments:

- In order for the merged payload to be a correct W3C VC, "given_name",
"family_name", "birthdate" should be inside a "credentialSubject" claim
- The claim names defined in
"https://www.w3.org/2018/credentials/examples/v1; are "givenName" and
"familyName" (I also dislike contexts, but some may complain).

Having saying these, I believe the following will produce a "merged payload"
which will be a valid W3C vc-data-model VC.

...
"sd_digests": {
   "vc":{
   "credentialSubject" {
  "givenName":
"fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
  " familyName":
"9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
  "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
 }
}
 }

Thanks,
Nikos


-Original Message-
From: Kristina Yasuda  
Sent: Wednesday, June 29, 2022 5:32 AM
To: Nikos Fotiou ; Daniel Fett 
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

Hi Nikos,

Regarding the example 4, the way vc-data-model v1.1 has defined mapping of a
data-model into a JWT (https://www.w3.org/TR/vc-data-model/#json-web-token),
there are (roughly) three types of claims in a JWT-VC. 
1) newly defined `vc` claim that includes all properties of the
vc-data-model that do not have an equivalent JWT claim (i.e.
credentialSubject property is included under a `vc` claim)
2) IANA registered JWT claims that have equivalent properties in the
vc-data-model (i.e. expirationDate property is mapped to an `exp` JWT claim)
3) JWT claims that do not have equivalent property defined in the
vc-data-model, but are required for a complete JWT-VC, such as "nonce",
"aud" to prevent replay, MITM.

The logic behind example 4 in the SD-JWT draft is that we have chosen to
treat `sd_digests` as a claim of type 3, hence it is a top level JWT-VC
claim.

Given what is (and is not) defined in W3C vc-data-model, I do not think
there is right or wrong way of how to include `sd_digests` in a W3C
vc-data-model signed as a JWS.


"merge payload" that Daniel mentions might look something like below:

Take an SD-JWT as below:
 "vc": {
   "@context": [
 "https://www.w3.org/2018/credentials/v1;,
 "https://www.w3.org/2018/credentials/examples/v1;
   ],
   "type": [
 "VerifiableCredential",
 "UniversityDegreeCredential"
   ]
 },
 "sd_digests": {
   "vc":{
   "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
   "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
   "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
}
 }
   }
And merge it into
 "vc": {
   "@context": [
 "https://www.w3.org/2018/credentials/v1;,
 "https://www.w3.org/2018/credentials/examples/v1;
   ],
   "type": [
 "VerifiableCredential",
 "UniversityDegreeCredential"
   ],
 "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
 "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
 "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
 }


Majority of JWT-VC implementations do not use "@context" property of
vc-data-model, so I would be reluctant to put information on which claim is
an SD claim there.


Quick note that we are defining SD-JWT not only for W3C vc-data-model
use-cases.

Best,
Kristina

-Original Message-
From: OAuth  On Behalf Of Nikos Fotiou
Sent: Tuesday, June 28, 2022 5:47 AM
To: Daniel Fett 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

Hi,

You are saying "merge payload". But how? In example 4 of section A.3,
"given_name", "family_name", "birthdate" must be moved inside the "vc" claim
to produce a valid payload. But nothing indicates that.
  
Best,
Nikos

--
Nikos Fotiou -
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpages.cs.au
eb.gr%2F~fotioudata=05%7C01%7CKristina.Yasuda%40microsoft.com%7C2cbddc2
095e3403fe52708da59044a5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63792
0172247431677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=VAnkhAYinJ45Lphov%2Fk
8PjxIp0o%2FTKxcnNUnuqwtYfw%3Dreserved=0
Researcher - Mobile 

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Nikos Fotiou]

Hi,

You are saying "merge payload". But how? In example 4 of section A.3, 
"given_name", "family_name", "birthdate" must be moved inside the "vc" claim to 
produce a valid payload. But nothing indicates that.

Best,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 28 Jun 2022, at 2:54 PM, Daniel Fett  wrote:
>
> Hi Nikos,
>
> Am 28.06.22 um 13:22 schrieb Nikos Fotiou:
>> Hi Daniel,
>>
>> I just want to reverse your arguments and I will stop spamming. I will focus 
>> on your “sub” example.
>>
>> When a VC is encoded as a JWT, and according to specs 
>> (https://www.w3.org/TR/vc-data-model/#proof-formats) “sub MUST represent the 
>> id property contained in the credentialSubject” and the VC must be
>> signed. Similarly,  RFC 7253 JWT requires the “sub” claim to exist and the 
>> token to be signed. By moving “sub” to “sd_digests” you don’t have a valid 
>> VC or JWT. Similarly, by merging “the released claims into the plain-text 
>> claims and produce a plain-text JSON”  also results in non-valid VCs/JWTs 
>> since signature verification will fail.
> There is no need to move sub to sd_digests, it can be left outside.
>
> The signature verification obviously must be done by the verification 
> algorithm before the merging. I don't imagine that the output of the 
> verification algorithm will be a signed JWT (since it can't produce the 
> signature), but just the payload. So instead of, for regular JWTs,
>
> receive JWT -> check signature -> extract payload -> work with payload,
>
> you would here have
>
> receive SD-JWT -> check signature -> verify SD claims -> merge payload -> 
> work with payload.
>
> -Daniel
>



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Nikos Fotiou]

Hi Daniel,

 

I just want to reverse your arguments and I will stop spamming. I will focus on 
your “sub” example.

 

When a VC is encoded as a JWT, and according to specs 
(https://www.w3.org/TR/vc-data-model/#proof-formats) “sub MUST represent the id 
property contained in the credentialSubject” and the VC must be 

signed. Similarly,  RFC 7253 JWT requires the “sub” claim to exist and the 
token to be signed. By moving “sub” to “sd_digests” you don’t have a valid VC 
or JWT. Similarly, by merging “the released claims into the plain-text claims 
and produce a plain-text JSON”  also results in non-valid VCs/JWTs since 
signature verification will fail.

 

Finally, I would like to bring to everybody’s attention this draft 
https://w3c-ccg.github.io/Merkle-Disclosure-2021/jwp/ It has the same goals as 
SD-JWT but it makes no modification to the actual JSON object, instead all 
information required to validate a proof is in the signature. I believe this is 
a cleaner approach since you can re-use existing infrastructure simply by 
adding support for a new signature type. 

 

Best,

Nikos

 

From: Daniel Fett  
Sent: Tuesday, June 28, 2022 1:17 PM
To: Nikos Fotiou ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

 

Hi Nikos,

the requirement for putting the claims into a separate structure becomes more 
obvious from your example.

On the surface, you can see that the data types don't match the specifications 
- the email address is not an email address, the phone number is not a phone 
number, the address even has a completely different data type.

Digging a bit deeper, the JWT in your example suggests that the issuer attests 
that the user has the sub 'LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04' and the 
given_name 'fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs'. This is absolutely 
not what the issuer wants to attest, but not clearly communicated in the JWT. 
This is ambgiuous to anyone interpreting the JWT, especially if they are 
unaware of the SD-JWT format, and various security problems can arise from 
that. Putting the claims into a separate container makes the distinction 
explicit.

Conversely, there is not really much to gain here by adhering - on the surface! 
- to an existing structure. We are messing up types, as described above, and 
contents. Anybody interpreting an SD-JWT needs to implement verification logic 
anyway, so why bother hiding the differences behind a familiar looking 
structure? I don't think that this impedes integration, but rather fosters 
clean implementations.

A verification algorithm can merge the released claims into the plain-text 
claims and produce a plain-text JSON that can then be fed into whatever 
algorithm uses the contents. This is a trivial programming exercise.

Regarding your proposal with the array below: This format does not work well 
with structured claims (see Examples 2 and 3).

-Daniel

 

Am 28.06.22 um 10:30 schrieb Nikos Fotiou:

  

> If the SD-JWT-R does not contain all claim names, the verifier might not be 
> able to tell whether a particular claim is an SD claim or a plain-text claim.

 

It is not obvious (at least to me) why the verifier needs to know that. 
Moreover, I agree that this approach is unambiguous but, IMHO, it is not clean 
and it impedes integration (e.g., as I wrote in the previous email example 4 is 
(probably) wrong). If a verifier really needs to know which claim is an SD 
claim, I believe a cleaner approach is to indicate this using out-of-band 
mechanisms, e.g., provide this information in a schema, in a VC “context”,  
documentation.  Alternatively,  `sd_digests` can be  just as an array that 
indicates the SD claims, e.g., example 1 in section 5.2 could be:

 

{

"iss":  <https://example.com/issuer> https://example.com/issuer,

"sub_jwk": {

"kty": "RSA",

"n": 
"pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw",

"e": "AQAB"

},

"hash_alg": "sha-256",

"iat": 1516239022,

"exp": 1516247022,

"sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",

"given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",

"family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",

"email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA",

"phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M",

"address": "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs",

"birthdate":

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Nikos Fotiou]

Hi Daniel,

 

> If the SD-JWT-R does not contain all claim names, the verifier might not be 
> able to tell whether a particular claim is an SD claim or a plain-text claim.

 

It is not obvious (at least to me) why the verifier needs to know that. 
Moreover, I agree that this approach is unambiguous but, IMHO, it is not clean 
and it impedes integration (e.g., as I wrote in the previous email example 4 is 
(probably) wrong). If a verifier really needs to know which claim is an SD 
claim, I believe a cleaner approach is to indicate this using out-of-band 
mechanisms, e.g., provide this information in a schema, in a VC “context”,  
documentation.  Alternatively,  `sd_digests` can be  just as an array that 
indicates the SD claims, e.g., example 1 in section 5.2 could be:

 

{

"iss":  <https://example.com/issuer> https://example.com/issuer,

"sub_jwk": {

"kty": "RSA",

"n": 
"pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw",

"e": "AQAB"

},

"hash_alg": "sha-256",

"iat": 1516239022,

"exp": 1516247022,

"sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",

"given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",

"family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",

"email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA",

"phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M",

"address": "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs",

"birthdate": "Ia1Tc6_Xnt5CJc2LtKcu6Wvqr42glBGGcjGOye8Zf3U",

"sd_digests":["sub", "given_name", "family_name", "email", "phone_number", 
"address", "birthdate"]

}

 

Best,

Nikos

 

From: OAuth  On Behalf Of Daniel Fett
Sent: Tuesday, June 28, 2022 10:30 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

 

Hi Nikos,

Am 24.06.22 um 16:16 schrieb Nikos Fotiou:

Hi,
I was wondering what is the reason for introducing the sd_digests claim. I 
think it complicates integration with existing systems. For example, I am 
pretty sure that the VC included in Example 4 is wrong. Since the verifier can 
learn from the SD-JWT-RELEASE which claims are hashed, why is it necessary to 
nest them under the sd_digests claim?

The idea is to have a clean, unambiguous seperation between the two. If the 
SD-JWT-R does not contain all claim names, the verifier might not be able to 
tell whether a particular claim is an SD claim or a plain-text claim. 



Also a small detail: if you decode the token at the end of section 5.2, instead 
of "sd_digests" it uses "_sd"

Good catch, we'll update the examples. We have opened an issue for that:  
<https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/79> 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/79

Thanks,
Daniel

 
 
Best,
Nikos
--
Nikos Fotiou -  <http://pages.cs.aueb.gr/~fotiou> 
http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
 <https://mm.aueb.gr> https://mm.aueb.gr
 

On 23 Jun 2022, at 7:32 PM, Daniel Fett  
<mailto:mail=40danielfett...@dmarc.ietf.org> 
 wrote:
 
All,
 
Kristina and I would like to bring to your attention a new draft that we have 
been working on with many others over the past weeks. "Selective Disclosure JWT 
(SD-JWT)" describes a format for signed JWTs that support selective disclosure 
(SD-JWT), enabling sharing only a subset of the claims included in the original 
signed JWT instead of releasing all the claims to every verifier. 
 
 
<https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html>
 
https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
 
Initial feedback we got was positive and we now would like to hear from the 
working group with the eventual goal of asking for working group adoption.
 
Issues are tracked in our GitHub repository:  
<https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues> 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues
 
The approach to selective disclosure described in the document is based on 
salted hashes. We have discussed and explored other approaches based on 
encryption as well. If you are interested in following this discussion, we 
would like t

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Nikos Fotiou]

Hi,
I was wondering what is the reason for introducing the sd_digests claim. I 
think it complicates integration with existing systems. For example, I am 
pretty sure that the VC included in Example 4 is wrong. Since the verifier can 
learn from the SD-JWT-RELEASE which claims are hashed, why is it necessary to 
nest them under the sd_digests claim?

Also a small detail: if you decode the token at the end of section 5.2, instead 
of "sd_digests" it uses "_sd"

Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 23 Jun 2022, at 7:32 PM, Daniel Fett  
> wrote:
>
> All,
>
> Kristina and I would like to bring to your attention a new draft that we have 
> been working on with many others over the past weeks. "Selective Disclosure 
> JWT (SD-JWT)" describes a format for signed JWTs that support selective 
> disclosure (SD-JWT), enabling sharing only a subset of the claims included in 
> the original signed JWT instead of releasing all the claims to every verifier.
>
> https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
>
> Initial feedback we got was positive and we now would like to hear from the 
> working group with the eventual goal of asking for working group adoption.
>
> Issues are tracked in our GitHub repository: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues
>
> The approach to selective disclosure described in the document is based on 
> salted hashes. We have discussed and explored other approaches based on 
> encryption as well. If you are interested in following this discussion, we 
> would like to invite you to read this issue: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30
>
> One main goal with this work is that the format should be easy to implement, 
> requiring little more than a regular JWT library. Three working 
> implementations show that this goal has been achieved: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations
>
> We are looking forward to your feedback!
>
> -Daniel
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] proof of access token possession using client secret

[Nikos Fotiou]

Hi all,

I am working on a use case where the Authorization Server and the Resource 
Server are the same entity. I would like to prevent clients from sharing their 
access tokens. I am wondering if requiring clients to include the "client 
secret" in the resource access request (in addition to the access token) is a 
valid strategy. This way clients would have to share their "client secret" in 
addition to the access token. Would that work?

Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] can a resource server provide indications about expected access tokens?

[Nikos Fotiou]

Thanks Vladimir,
I am looking for something which is machine readable so that clients can handle 
the error automatically.

Best,
Nikos

> On 11 Dec 2021, at 12:44 PM, Vladimir Dzhuvinov  
> wrote:
> 
> 
> Hi Nikos,
> 
> The "error_description" can be used to explain the expected token issuer and 
> other facts to client developers.
> 
> https://datatracker.ietf.org/doc/html/rfc6750#section-3
> 
> If you want to give client software the ability to respond programmatically 
> this will require some sort of a proprietary extension.
> 
> Vladimir
> 
> Vladimir Dzhuvinov
> On 11/12/2021 12:35, Nikos Fotiou wrote:
>> Hi,
>> 
>> I have a use case where a resource server is protected  and can only be 
>> accessed if a JWT is presented. Is there any way for the server to 
>> "indicate" the "expected" format of the JWT. For example,  respond to 
>> unauthorized requests with something that would be translated into "I expect 
>> tokens form iss X with claims [A,B,C]"
>> 
>> Best,
>> Nikos
>> 
>> --
>> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
>> Researcher - Mobile Multimedia Laboratory
>> Athens University of Economics and Business
>> https://mm.aueb.gr
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] can a resource server provide indications about expected access tokens?

[Nikos Fotiou]

Hi,

I have a use case where a resource server is protected  and can only be 
accessed if a JWT is presented. Is there any way for the server to "indicate" 
the "expected" format of the JWT. For example,  respond to unauthorized 
requests with something that would be translated into "I expect tokens form iss 
X with claims [A,B,C]"

Best,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP, how will it be implemented in a browser?

[Nikos Fotiou]

Hi,
How do you believe DPoP will be implemented in a browser? In particular, how 
the browser will retrieve client's private key and generate the appropriate 
signature? Do you imagine interoperability with a specification such as 
WenAuthN? Something else (e.g., DPoP-enabled "wallets")? 

Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] self-issued access tokens

[Nikos Fotiou]

> Are you using DPoP at issuance of the credential and embedding the public
key as the means to verify the subject? 
Exactly. We are using "client credentials" as grant type. The credential
used as grant is client's public key and we are using DPoP to prove
possession. Then the public key is embedded in the VC (which is encoded as a
JWT). 

 > Are you going so far as using DPoP in lieu of Verifiable Presentation
wrappers?
Yes. Since our VCs are encoded in JWT, they are included in the
Authorization header of HTTP  requests and we are using DPoP to prove
possession. So we do not use Verifiable Presentations at all.

Best,
Nikos

> On Sep 30, 2021, at 12:47 AM, Nikos Fotiou  wrote:
> 
> FYI, this is exactly what we are doing in [1] to manage Verifiable
Credentials using OAuth2.0. The AS issues a verifiable credential that stays
(for long time) in the client. The client uses DPoP to prove ownership of
the credential. We just started a new project funded by essif [2] that will
further develop this idea and provide implementations.
> 
> Best,
> Nikos
> 
> [1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access 
> control for multi-tenant systems using Oauth 2.0 and Verifiable 
> Credentials," Proc. 30th International Conference on Computer 
> Communications and Networks (ICCCN), Athens, Greece, July 2021 
> (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.
> pdf)
> [2]https://essif-lab.eu
> --
> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile 
> Multimedia Laboratory Athens University of Economics and Business 
> https://mm.aueb.gr



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] self-issued access tokens

[Nikos Fotiou]

FYI, this is exactly what we are doing in [1] to manage Verifiable Credentials 
using OAuth2.0. The AS issues a verifiable credential that stays (for long 
time) in the client. The client uses DPoP to prove ownership of the credential. 
We just started a new project funded by essif [2] that will further develop 
this idea and provide implementations.

Best,
Nikos

[1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access control for 
multi-tenant systems using Oauth 2.0 and Verifiable Credentials," Proc. 30th 
International Conference on Computer Communications and Networks (ICCCN), 
Athens, Greece, July 2021 
(https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf)
[2]https://essif-lab.eu
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 29 Sep 2021, at 6:42 PM, Daniel Fett  wrote:
> 
> That very much sounds like a static string as the access token plus DPoP.
> 
> -Daniel
> 
> Am 29.09.21 um 03:54 schrieb toshio9@toshiba.co.jp:
>> Hi OAuth folks,
>> 
>> I have a question. Is there (or was there) any standardizing effort for
>> "self-issued access tokens"?
>> 
>> Self-issued access tokens are mentioned in a blog post by P. Siriwardena in 
>> 2014
>> [*1]. It's an Access Token issued by the Client and sent to the Resource 
>> Server.
>> The token is basically a signed document (e.g. JWT) by the private key of the
>> Client. The Resource Server verifies the token with the public key, which is
>> provisioned in the RS in advance.
>> 
>> I think self-issued access tokens are handy replacement for Client 
>> Credentials
>> Grant flow in simple deployments, where it's not so necessary to separate AS 
>> and
>> RS. In fact, Google supports this type of authentication for some services
>> [*2][*3]. I'm wondering if there are any other services supporting 
>> self-signed
>> access tokens.
>> 
>> Any comments are welcome.
>> 
>> [*1]: 
>> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
>> 
>> [*2]: 
>> https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth
>> 
>> [*3]: 
>> https://google.aip.dev/auth/4111
>> 
>> 
>> -
>> Toshio Ito
>> Research and Development Center
>> Toshiba Corporation
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> 
> https://danielfett.de
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP key rotation

[Nikos Fotiou]

Hi,

For a research project we have implemented key rotation by leveraging “Token 
Introspection” (see section 6.2 here 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2 ) Of 
course the drawback of this approach is that the authorization server must 
always know the current key of the client.

 

Best,

Nikos

 

From: OAuth  On Behalf Of Dmitry Telegin
Sent: Tuesday, June 8, 2021 7:30 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] DPoP key rotation

 

Hi,

 

I'm Dmitry Telegin, I'm currently working on DPoP implementation in Keycloak on 
behalf of my company, Backbase. Takashi Norimatsu of Hitachi supervises this 
process as the head of the Keycloak FAPI SIG.

 

With the current DPoP design, once the keypair has been generated on the user 
agent and the initial token set has been obtained (using authorization_code 
grant), the whole chain of the subsequent access/refresh tokens will be bound 
to this particular keypair. That means, the keypair should be persisted on the 
user agent for the duration of the session.

 

OTOH, sessions could be rather long-lived, especially if we take offline tokens 
[1] into account. In a nutshell, offline access provides a non-expiring refresh 
token. This could be highly relevant e.g. for mobile applications that would 
employ offline tokens to help users avoid logging in every time.

 

The longer the session lasts, the higher the probability of key leakage is. 
Currently, the only way to switch to a new DPoP keypair is to start a new 
session (i.e. log in again). Do you think it might be worth incorporating some 
sort of key rotation concept into DPoP design?

 

The most obvious way to perform key rotation is to do that during token 
refresh. For that, we could make the refresh_token grant honour the additional 
DPoP proof that would supersede the current one. From the technical PoV, it 
could be as easy as supplying two proofs within the DPoP header:

 

DPoP: eyJ0eXAiO... eyJ0eXAiO...
Or we can go with a single (old) DPoP proof, containing the new proof (to 
supersede the current one) as a claim (or vice versa).
We'd appreciate any feedback from the WG. Also apologize if this ML is not the 
appropriate place to discuss issues like this.
Regards,
Dmitry Telegin
Senior Backend Engineer, Backbase R B.V.

[1] https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] dpop terminogly

[Nikos Fotiou]

Hi I am wondering if the following terminology is more appropriate for the DPoP 
draft (https://tools.ietf.org/html/draft-fett-oauth-dpop-04):
- Since a DPoP proof is a JWT encoded in a JWS may be it is better to say "DPoP 
proof payload" instead of "DPoP proof body" (end of page 4).
- For the same reason use "JOSE header" instead of "JSON header" (beginning of 
page 5)
- Moreover, here and there it is stated "the header of the JWT". AFAIU JWTs do 
not have headers themselves but the header is part of the JWS/JWE structure in 
which the JWT is encoded. So may be it is more appropriate to say "the JOSE 
header" instead of "the header of the JWT". 

Best,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Nikos Fotiou]

Hi,
By reading this draft 
(https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-05) I got the 
impression that it implies using JWTs as bearer tokens, e.g., it does consider 
any of the semantics defined in RFC7800. Is this correct? If yes what was the 
rational behind this design choice?

Thanks a lot,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token substitution in DPoP

[Nikos Fotiou]

Hi,
The token is granted to a client based on the authorization grant and not the 
client's key. Therefore, a client may use a different key per token. At least 
this is an approach we are following. 

Best,
Nikos

-Original Message-
From: OAuth  On Behalf Of Justin Richer
Sent: Friday, November 20, 2020 9:26 PM
To: oauth 
Subject: [OAUTH-WG] Token substitution in DPoP

While working on an implementation of DPoP recently, I realized that the value 
of the access token itself is not covered by the DPoP signature at all. What 
I’m wondering is whether or not this constitutes an attack surface that we care 
about here. Here’s how it works:


Let’s say that a client creates a DPoP key and uses that key to request two 
tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is 
malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s 
token value, T2, through some means. Normally DPoP wouldn’t let Alice create a 
new request using T2 since Alice doesn’t have the client’s key. However, if 
Alice gets the client to create a request for her using T1, she can copy the 
signature from that request onto a new request using T2. Since the signature 
doesn’t cover the token value and the key is the same, the RS should accept 
both requests, right?

An important aspect is that the parts needed to make this attack work are a 
little weird: you’d need access to a valid signed request from the client with 
T1 as well as access to a valid T2 attached to the same key in order to make 
this substitution. However, this is effectively the same attack area that 
bearer tokens have in a lot of ways, since it doesn’t require the attacker 
gaining access to the singing key to generate or modify a signature, nor does 
it require the attacker to generate or modify an access token (merely obtain 
one).


I’d like to understand if this is an actual attack against DPoP. If it isn’t, 
how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? I 
didn’t see a mention of it there. If it’s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access token 
itself inside the signature body instead of a second header. Another option 
would be to include a hash of the token value (such as OIDC’s “at_hash” method 
used in ID Tokens) in the DPoP payload. With either of these approaches, Alice 
having access to T1, T2, and a signed message for T1 does not allow her to use 
T2 effectively.

 — Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

[Nikos Fotiou]

Hi all,

There was some discussion about adding “server contribution” in the DPoP proof. 
I was wondering if the “challenge” server response described in section 6 can 
include such a contribution (e.g., a server generated nonce).

 

Best,

Nikos

 

From: OAuth  On Behalf Of Brian Campbell
Sent: Friday, May 1, 2020 10:03 PM
To: oauth 
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-ietf-oauth-dpop-01.txt

 

I've pushed out a -01 revision of DPoP hopefully allowing folks enough time to 
read it before the interim meeting on Monday (apologies that it wasn't sooner 
but the edits took longer than expected or hoped). For ease of reference the 
changes in this revision are summarized below. There are, of course, still 
outstanding issues and discussion points that I hope to make some progress on 
during the interim meeting on Monday.

 

   -01


   *  Editorial updates
   *  Attempt to more formally define the DPoP Authorization header
  scheme
   *  Define the 401/WWW-Authenticate challenge
   *  Added "invalid_dpop_proof" error code for DPoP errors in token
  request
   *  Fixed up and added to the IANA section
   *  Added "dpop_signing_alg_values_supported" authorization server
  metadata
   *  Moved the Acknowledgements into an Appendix and added a bunch of
  names (best effort)

 

-- Forwarded message -
From: mailto:internet-dra...@ietf.org> >
Date: Fri, May 1, 2020 at 12:24 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
To: Torsten Lodderstedt mailto:tors...@lodderstedt.net> >, David Waite mailto:da...@alkaline-solutions.com> >, John Bradley mailto:ve7...@ve7jtb.com> >, Brian Campbell mailto:bcampb...@pingidentity.com> >, Daniel Fett mailto:m...@danielfett.de> >, Michael Jones mailto:m...@microsoft.com> >




A new version of I-D, draft-ietf-oauth-dpop-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:   draft-ietf-oauth-dpop
Revision:   01
Title:  OAuth 2.0 Demonstration of Proof-of-Possession at the 
Application Layer (DPoP)
Document date:  2020-05-01
Group:  oauth
Pages:  22
URL:
https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Htmlized:   https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-01

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
 .

The IETF Secretariat




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.



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Nikos Fotiou]

Just a general comment, OIDC has been designed for a specific reason (“identity 
layer on top of the OAuth 2.0”) whereas JWT access tokens are used for more 
applications. Since the goal of this specification is to “provide a 
standardized and interoperable profile as an alternative to the proprietary JWT 
access tokens layout”,  I feel it is restrictive.

 

Best,

Nikos 

 

From: Vittorio Bertocci  
Sent: Tuesday, March 24, 2020 7:57 PM
To: Nikos Fotiou 
Cc: Hannes Tschofenig ; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

Hi Nikos,

thanks for taking the time to review and write down your feedback!

Inline

 

- In Section 2.2 why nbf claim 
(https://tools..ietf.org/html/rfc7519#section-4.1.5) 
<https://tools.ietf.org/html/rfc7519#section-4.1.5)>  is not considered? I can 
imagine some interesting applications of this claim.  

The validation rules are partly following the ones defined in OpenID Connect, 
given that a lot of in market deployments reuse some low level JWT validation 
components.

 

  - In the same section, it is not clear why some claims are required, 
especially exp, sub, and client_id. The last two claims are not even used 
during token validation. 

 Being this an interop profile, it reflects the information commonly found in 
many existing JWT based access tokens solutions in the wild. Both sub and 
client_id provide information that proved to be useful to RSes and 
SDKs/middlewares, hence guaranteeing their presence will help creating reusable 
libraries with broader applicability. The AS has ready access to that info, and 
there are no obvious security reasons for omitting them. Also, sub and exp are 
both required in OIDC, and clientID is available via aud (also required) - 
hence requiring their presence helps developers to reuse existing validation 
logic to at least some extent.

 

  - RFC7519 specifies that, in the general case, the aud claim is an array of 
StringOrURI values. In this draft it is not clear if this still the case, or 
here aud is a simple string (e.g., in page 5 it is stated: the resource 
indicated in the aud claim, rather than the resource*s*).  

For simplicity, and above all for avoiding ambiguity in evaluating to what 
resource the granted scopes should be applied to, the idea would be to restrict 
to a single string.

 

  - In the token validation procedure, i.e., Section 4, is there any reason why 
the resource server first checks the aud claim, then the signature, and finally 
the exp claim? Given the fact that Error responses are not specified, returning 
something like “invalid aud claim” even for tokens with invalid signature may 
result in privacy/security attacks. 

 The sequence of those checks follows 
https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation.  As 
OIDC doesn't define error responses nor call this aspect out in the security 
considerations, I largely relied on this being mainstream.

 

  - IMHO The token validation procedure it too bound to the particular 
discovery mechanisms mentioned at the beginning of this section. E.g., Step 2 
mentions a “registration” process, and Step 3 mentions and an “Issuer 
Identifier” which must much the iss claim. Moreover, I think it should be 
explicitly mentioned that the resource server “must validate that the JWT 
access token has been singed with a signing key that corresponds to the 
authorization server included in the iss claim”

As per the other points, the language follows closely OIDC. 

The step does contain the phrase "The resource server MUST use the keys 
provided by the authorization server." Do you feel the language should be more 
explicit? The document doesn't specify any other mechanism for acquiring keys, 
hence it shouldn't be too ambiguous... but we can always tighten it up.

 

 

On Mon, Mar 23, 2020 at 6:32 PM Nikos Fotiou mailto:fot...@aueb.gr> > wrote:

Hi all,

 

Allow me some comments and forgive me if some of them are naïve.

- In Section 2.2 why nbf claim 
(https://tools..ietf.org/html/rfc7519#section-4.1.5) 
<https://tools.ietf.org/html/rfc7519#section-4.1.5)>  is not considered? I can 
imagine some interesting applications of this claim.

- In the same section, it is not clear why some claims are required, especially 
exp, sub, and client_id. The last two claims are not even used during token 
validation.

- RFC7519 specifies that, in the general case, the aud claim is an array of 
StringOrURI values. In this draft it is not clear if this still the case, or 
here aud is a simple string (e.g., in page 5 it is stated: the resource 
indicated in the aud claim, rather than the resource*s*).

- In the token validation procedure, i.e., Section 4, is there any reason why 
the resource server first checks the aud claim, then the signature, and finally 
the exp claim? Given the fact that Error responses are not specified, returning 
something li

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

[Nikos Fotiou]

Hi all,

 

Allow me some comments and forgive me if some of them are naïve.

- In Section 2.2 why nbf claim
(https://tools.ietf.org/html/rfc7519#section-4.1.5) is not considered? I can
imagine some interesting applications of this claim.

- In the same section, it is not clear why some claims are required,
especially exp, sub, and client_id. The last two claims are not even used
during token validation.

- RFC7519 specifies that, in the general case, the aud claim is an array of
StringOrURI values. In this draft it is not clear if this still the case, or
here aud is a simple string (e.g., in page 5 it is stated: the resource
indicated in the aud claim, rather than the resource*s*).

- In the token validation procedure, i.e., Section 4, is there any reason
why the resource server first checks the aud claim, then the signature, and
finally the exp claim? Given the fact that Error responses are not
specified, returning something like “invalid aud claim” even for tokens with
invalid signature may result in privacy/security attacks.

- IMHO The token validation procedure it too bound to the particular
discovery mechanisms mentioned at the beginning of this section. E.g., Step
2 mentions a “registration” process, and Step 3 mentions and an “Issuer
Identifier” which must much the iss claim. Moreover, I think it should be
explicitly mentioned that the resource server “must validate that the JWT
access token has been singed with a signing key that corresponds to the
authorization server included in the iss claim”  

 

 

Best,

Nikos

 

From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, March 23, 2020 11:18 PM
To: oauth 
Subject: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens"

 

Hi all,

 

this is a working group last call for "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens".

 

Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04 

 

Please send you comments to the OAuth mailing list by April 6, 2020.

 

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you. 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth