[OAUTH-WG] I-D Action: draft-ietf-oauth-resource-metadata-01.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-resource-metadata-01.txt is now available. It
is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   OAuth 2.0 Protected Resource Metadata
   Authors: Michael B. Jones
Phil Hunt
Aaron Parecki
   Name:draft-ietf-oauth-resource-metadata-01.txt
   Pages:   22
   Dates:   2023-10-20

Abstract:

   This specification defines a metadata format that an OAuth 2.0 client
   or authorization server can use to obtain the information needed to
   interact with an OAuth 2.0 protected resource.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-01

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-resource-metadata-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [OAUTH-WG] SD-JWT explicit guidance on parsing json strings

[Carsten Bormann]

Hi Denis,

you address me directly in this message, but there is not much in there I’d 
care to reply to.
However, some people might believe what you are saying here:

> On 16. Oct 2023, at 15:24, Denis  wrote:
> 
> Structures can be generated using CDDL, but can't be validated 
> against CDDL. RFC 8610 does not enable an automatic validation of CBOR data 
> items against an expected schema, in the same way 
> as this is possible using either ASN.1 / DER or XSD. 

Please do check the facts before making seemingly authoritative statements 
about things you haven’t studied.

Grüße, Carsten

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

[OAUTH-WG] Updated "OAuth for First-Party Apps" draft

[Aaron Parecki]

Hi all,

The authors have finished incorporating the changes discussed at the last
meeting and published a new draft:

https://www.ietf.org/archive/id/draft-parecki-oauth-first-party-apps-00.html

Highlights include:

• Renamed "device_session" to "auth_session" (feel free to continue
bikeshedding this during the next meeting)
• Added a way for the AS to indicate that the client should bounce out to a
browser
• Described how to use DPoP in conjunction with this spec
• Added example of using a passkey to get an authorization code

Here is the full list of issues we addressed in this revision:

https://github.com/aaronpk/oauth-first-party-apps/milestone/2?closed=1

I look forward to continuing the discussion at IETF 118!

---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Updated Transaction Tokens draft

[Atul Tulshibagwale]

Hi all,
Here is the updated Transaction Tokens draft, which is on the agenda for
Prague. In the new draft, we have incorporated the feedback received in
IETF 117, as well as removed the "Nested Transaction Tokens" part. Salient
points are:

   1. Transaction Tokens now have separate claims for:
  - Requester context, with defined optional fields within it.
  - Purpose
  - Authorization details
   2. There is now an audience claim, whose value is the trust domain of
   the Transaction Token
   3. Removed nesting and as a result the draft no longer depends on the
   jWT Embedded Tokens draft.

https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/05/

Looking forward to discussing this in Prague,
Atul
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT explicit guidance on parsing json strings

[David Waite]

> On Oct 13, 2023, at 6:57 PM, Orie Steele  wrote:
> 
> 
> riffing on this, if it's possible to use a "simple and safe parser on the 
> untrusted data", before using a "maybe safe / probably fast " parser on the 
> trusted data, maybe do that : )
> 
>> This is also not dissimilar to additional effort CBOR specs make to reduce 
>> optionality/variability in formats. That said, the vast majority of relying 
>> parties (e.g. all but one implementation) will likely use off-the-shelf JSON 
>> parsers for this data, which could very well be coming from a malicious 
>> client.
> 
> So bad guys are going to get their malicious JSON to relying parties, and 
> relying parties are going to process the JSON (with the finest of JSON 
> parsers)... no matter what we say in SD-JWT ? : )

Just sayin’. The ‘deterministic’ CollectedClientData was added for one vendor, 
and AFAIK they are still the only vendor using that feature.

In return, we got a much harder job evolving in the future, as we can’t use the 
‘ignore what you don’t understand’ extensibility model typical of JSON data 
formats.

> Must be nice to have a JSON parser that returns the last duplicate member... 
> but also doesn't have any active CVEs.

I do wonder if timing had been different if JWS and JWT would have been based 
on I-JSON.

This behavior is most likely described because JSON leaves it entirely 
non-deterministic. If I have two separate components parsing the data in a 
chain, I’ll either have one/both error out or both interpret the object the 
same way, vs having one operate on the first property value and the other 
operate on the second.

-DW

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

Re: [OAUTH-WG] Clarification on SD-JWT verification

[Brian Campbell]

Agree that it should be clarified. Being precise with language around this
stuff is tricky. But my understanding of the intent was to ensure that no
digest value is repeated in the whole of the SD-JWT - either in the payload
directly or recursively in any Disclosure. Because of the trickiness of
language, I'm not sure if we disagree or not about the intent...

On Fri, Oct 20, 2023 at 8:09 AM Daniel Fett  wrote:

> Hi Jacob,
>
> the intention was to cover the first case you listed. We should clarify
> this.
>
> -Daniel
> Am 20.10.23 um 15:02 schrieb Jacob Ward:
>
> Hello again,
>
> On a similar note to my previous email, could I get some clarity on a step
> in the SD-JWT verification process?
>
>
>
> *4. If any digests were found more than once in the previous step, the
> SD-JWT MUST be rejected. *
> Step 4 in Section 6.1 (as shown above) could have multiple meanings in my
> opinion:
> - The digest was found multiple times (for example in an "_sd" array and
> as an array element).
> - More than one Disclosure have the same digest.
>
> On first reading of this I assumed that this step only covered the first
> of those two cases, but it has been pointed out to me by a colleague that
> it could cover both. If it is the case that both cases are covered by this
> step, then I think it would be helpful to clarify this in the text.
>
> Cheers,
>
> Jacob
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Please use my new email address: m...@danielfett.de
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT Redaction Reasons

[Orie Steele]

That's a much better place to communicate redaction reasons.

Although if the use case for communicating secured redaction reasons from
the holder to the verifier doesn't fit well with SD-JWT spec, it's possible
that's a profile specific thing, where interoperability matters less, so it
should be covered in another document.

And again, I tend to agree that this could lead to poor holder hygiene, and
"over sharing"... even issues where the holder accidentally reveals the
redacted claim, in their awkward attempt to provide a reason for its
redaction.

Perhaps an allow list / registry approach would be better than allowing
free form responses from the holder.

OS

On Fri, Oct 20, 2023 at 9:30 AM Daniel Fett  wrote:

> The Holder can put such information into the KB-JWT, if required.
>
> -Daniel
> Am 20.10.23 um 16:28 schrieb Orie Steele:
>
> In some ways this is related to the question about disclosures.
>
> On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> At least at the moment I don't think that there is a huge need for such a
>> feature. I don't think that we should clutter the existing SD-JWT data
>> structures with such information.
>>
> I tend to agree with the latter.
>
> There is substantial security / privacy risk, making disclosures carry ANY
> information other than what the issuer committed to.
>
>
>> If required, it could go into a separate data structure in the SD-JWT,
>> for example a list of JSON pointers with a mapping to the respective
>> redaction reasons.
>>
>
> This assumes the issuer knows why the holder chose not to disclose a
> field For some use cases that's probably a knowable thing... it also
> prevents the holder from using the disclosures as an unsecured channel to
> communicate with the verifier.
>
>
>> -Daniel
>> Am 18.10.23 um 05:03 schrieb Tom Jones:
>>
>> That's leaking the existence of PII. That requires permission of the
>> subject. I think it's way more complicated than you think.
>>
>> thx ..Tom (mobile)
>>
>> On Tue, Oct 17, 2023, 6:20 AM Orie Steele 
>>  wrote:
>>
>>> Hello,
>>>
>>> In government documents that feature redaction, it's common for the
>>> redaction to be given a reason.
>>>
>>> For example, in the Mueller report, we can see "Harm to Ongoing Matter",
>>> "Personal Privacy", "Investigative Technique", as well as "IT" and "HOM".
>>>
>>> In SD-JWT we see the following:
>>>
>>> Case 1
>>>
>>> "_sd": [
>>>   "IjCRF...znc", // disclosure hash
>>>   "Qdpt9pL...lhU9UDo" // disclosure hash
>>> ]
>>>
>>> and
>>>
>>> Case 2
>>>
>>> { "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash  }
>>>
>>> After verification and applying disclosures these annotations are no
>>> longer present.
>>>
>>> I wonder if it would be worth allowing a reason for why a holder might
>>> have retained a redaction (or chose not to disclose for a reason).
>>>
>>> Since the payload is committed to by the issuer, this information would
>>> have to be present in the disclosures collection for the SD-JWT.
>>>
>>> Here is an example disclosure:
>>>
>>> [
>>>   "8UbQ9NZ6xseoDqMW_Bd50A", // salt
>>>   "type", // json object key (always a string)
>>>   [ // json object value
>>> "VerifiableCredential",
>>> "ExampleAlumniCredential"
>>>   ]
>>> ]
>>>
>>> Consider the following strawman syntax for disclosing a redaction reason:
>>>
>>> {
>>>   "disclosure hash" : "Personal Privacy" || "Harm to Ongoing Matter"
>>> }
>>>
>>> This allows a UI to map the redaction reason into a presentation (ui)
>>> layer for the issuer secured payload.
>>>
>>> Since it's an unsecured object, it can be extended with other fields at
>>> the discretion of the holder or issuer.
>>>
>>> However it might be secured by nesting it inside another JWT or SD-JWT.
>>>
>>> It would only slightly complicate the verification logic, you would need
>>> to filter any encoded disclosures by the `ey` prefix, since they will never
>>> be found in the payload, as we know they will hash differently than array
>>> encoded disclosures, which will be found in the payload.
>>>
>>> I'll be giving a presentation on this topic to the W3C Credentials
>>> community group later today, happy to shuttle their reactions back to this
>>> list.
>>>
>>> Apologies if this has been discussed previously.
>>>
>>> Regards,
>>>
>>> OS
>>>
>>>
>>> --
>>>
>>>
>>> ORIE STEELE Chief Technology Officer www.transmute.industries
>>>
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>> --
>> Please use my new email address: m...@danielfett.de
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
>
>
> ORIE STEELE Chief Technology Officer 

Re: [OAUTH-WG] SD-JWT Verification strictness

[Jacob Ward]

Hi Daniel,

Thanks for the response, that makes total sense.

Jacob

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

Re: [OAUTH-WG] SD-JWT Redaction Reasons

[Daniel Fett]

The Holder can put such information into the KB-JWT, if required.

-Daniel

Am 20.10.23 um 16:28 schrieb Orie Steele:

In some ways this is related to the question about disclosures.

On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett 
 wrote:


At least at the moment I don't think that there is a huge need for
such a feature. I don't think that we should clutter the existing
SD-JWT data structures with such information.

I tend to agree with the latter.

There is substantial security / privacy risk, making disclosures carry 
ANY information other than what the issuer committed to.


If required, it could go into a separate data structure in the
SD-JWT, for example a list of JSON pointers with a mapping to the
respective redaction reasons.


This assumes the issuer knows why the holder chose not to disclose a 
field For some use cases that's probably a knowable thing... it 
also prevents the holder from using the disclosures as an unsecured 
channel to communicate with the verifier.


-Daniel

Am 18.10.23 um 05:03 schrieb Tom Jones:

That's leaking the existence of PII. That requires permission of
the subject. I think it's way more complicated than you think.

thx ..Tom (mobile)

On Tue, Oct 17, 2023, 6:20 AM Orie Steele
  wrote:

Hello,

In government documents that feature redaction, it's common
for the redaction to be given a reason.

For example, in the Mueller report, we can see "Harm to
Ongoing Matter", "Personal Privacy", "Investigative
Technique", as well as "IT" and "HOM".

In SD-JWT we see the following:

Case 1

"_sd": [
      "IjCRF...znc", // disclosure hash
      "Qdpt9pL...lhU9UDo" // disclosure hash
]

and

Case 2

{ "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash  }

After verification and applying disclosures these annotations
are no longer present.

I wonder if it would be worth allowing a reason for why a
holder might have retained a redaction (or chose not to
disclose for a reason).

Since the payload is committed to by the issuer, this
information would have to be present in the disclosures
collection for the SD-JWT.

Here is an example disclosure:

[
  "8UbQ9NZ6xseoDqMW_Bd50A", // salt
  "type", // json object key (always a string)
  [ // json object value
    "VerifiableCredential",
    "ExampleAlumniCredential"
  ]
]

Consider the following strawman syntax for disclosing a
redaction reason:

{
  "disclosure hash" : "Personal Privacy" || "Harm to Ongoing
Matter"
}

This allows a UI to map the redaction reason into a
presentation (ui) layer for the issuer secured payload.

Since it's an unsecured object, it can be extended with other
fields at the discretion of the holder or issuer.

However it might be secured by nesting it inside another JWT
or SD-JWT.

It would only slightly complicate the verification logic, you
would need to filter any encoded disclosures by the `ey`
prefix, since they will never be found in the payload, as we
know they will hash differently than array encoded
disclosures, which will be found in the payload.

I'll be giving a presentation on this topic to the W3C
Credentials community group later today, happy to shuttle
their reactions back to this list.

Apologies if this has been discussed previously.

Regards,

OS


-- 



ORIE STEELEChief Technology Officerwww.transmute.industries




___
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


-- 
Please use my new email address:m...@danielfett.de


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



--


ORIE STEELEChief Technology Officerwww.transmute.industries


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

Re: [OAUTH-WG] SD-JWT Redaction Reasons

[Orie Steele]

In some ways this is related to the question about disclosures.

On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett  wrote:

> At least at the moment I don't think that there is a huge need for such a
> feature. I don't think that we should clutter the existing SD-JWT data
> structures with such information.
>
I tend to agree with the latter.

There is substantial security / privacy risk, making disclosures carry ANY
information other than what the issuer committed to.


> If required, it could go into a separate data structure in the SD-JWT, for
> example a list of JSON pointers with a mapping to the respective redaction
> reasons.
>

This assumes the issuer knows why the holder chose not to disclose a
field For some use cases that's probably a knowable thing... it also
prevents the holder from using the disclosures as an unsecured channel to
communicate with the verifier.


> -Daniel
> Am 18.10.23 um 05:03 schrieb Tom Jones:
>
> That's leaking the existence of PII. That requires permission of the
> subject. I think it's way more complicated than you think.
>
> thx ..Tom (mobile)
>
> On Tue, Oct 17, 2023, 6:20 AM Orie Steele 
>  wrote:
>
>> Hello,
>>
>> In government documents that feature redaction, it's common for the
>> redaction to be given a reason.
>>
>> For example, in the Mueller report, we can see "Harm to Ongoing Matter",
>> "Personal Privacy", "Investigative Technique", as well as "IT" and "HOM".
>>
>> In SD-JWT we see the following:
>>
>> Case 1
>>
>> "_sd": [
>>   "IjCRF...znc", // disclosure hash
>>   "Qdpt9pL...lhU9UDo" // disclosure hash
>> ]
>>
>> and
>>
>> Case 2
>>
>> { "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash  }
>>
>> After verification and applying disclosures these annotations are no
>> longer present.
>>
>> I wonder if it would be worth allowing a reason for why a holder might
>> have retained a redaction (or chose not to disclose for a reason).
>>
>> Since the payload is committed to by the issuer, this information would
>> have to be present in the disclosures collection for the SD-JWT.
>>
>> Here is an example disclosure:
>>
>> [
>>   "8UbQ9NZ6xseoDqMW_Bd50A", // salt
>>   "type", // json object key (always a string)
>>   [ // json object value
>> "VerifiableCredential",
>> "ExampleAlumniCredential"
>>   ]
>> ]
>>
>> Consider the following strawman syntax for disclosing a redaction reason:
>>
>> {
>>   "disclosure hash" : "Personal Privacy" || "Harm to Ongoing Matter"
>> }
>>
>> This allows a UI to map the redaction reason into a presentation (ui)
>> layer for the issuer secured payload.
>>
>> Since it's an unsecured object, it can be extended with other fields at
>> the discretion of the holder or issuer.
>>
>> However it might be secured by nesting it inside another JWT or SD-JWT.
>>
>> It would only slightly complicate the verification logic, you would need
>> to filter any encoded disclosures by the `ey` prefix, since they will never
>> be found in the payload, as we know they will hash differently than array
>> encoded disclosures, which will be found in the payload.
>>
>> I'll be giving a presentation on this topic to the W3C Credentials
>> community group later today, happy to shuttle their reactions back to this
>> list.
>>
>> Apologies if this has been discussed previously.
>>
>> Regards,
>>
>> OS
>>
>>
>> --
>>
>>
>> ORIE STEELE Chief Technology Officer www.transmute.industries
>>
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Please use my new email address: m...@danielfett.de
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries


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

Re: [OAUTH-WG] Clarification on SD-JWT verification

[Daniel Fett]

Hi Jacob,

the intention was to cover the first case you listed. We should clarify 
this.


-Daniel

Am 20.10.23 um 15:02 schrieb Jacob Ward:

Hello again,

On a similar note to my previous email, could I get some clarity on a 
step in the SD-JWT verification process?


/4. If any digests were found more than once in the previous step, the 
SD-JWT MUST be rejected.


/
Step 4 in Section 6.1 (as shown above) could have multiple meanings in 
my opinion:
- The digest was found multiple times (for example in an "_sd" array 
and as an array element).

- More than one Disclosure have the same digest.

On first reading of this I assumed that this step only covered the 
first of those two cases, but it has been pointed out to me by a 
colleague that it could cover both. If it is the case that both cases 
are covered by this step, then I think it would be helpful to clarify 
this in the text.


Cheers,

Jacob

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT Verification strictness

[Daniel Fett]

Hi Jacob,

this check is mainly important for the Holder to ensure the integrity of 
the received SD-JWT. For the Verifier, there is not much to gain by 
checking this (but it also doesn't hurt either).


However, we intended to keep the algorithms for the Holder and Verifier 
similar and therefore decided to not make an exception for the Verifier 
here. It also enforces good "hygiene" for the Holder to not send any 
Disclosures that don't belong into the SD-JWT (for example, a Disclosure 
that originates from a claim in a recursive data structure, but where 
the parent claim is not disclosed to the Verifier). This can also help 
to avoid privacy problems.


-Daniel

Am 20.10.23 um 10:58 schrieb Jacob Ward:

Hello all,

Please let me know if there's a better channel to ask questions and/or 
raise issues with the SD-JWT spec.


Currently as part of verification of an SD-JWT the following is stated:

/Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that /

  * /the Issuer-signed JWT is valid, i.e., it is signed by the Issuer
and the signature is valid, and/
  * /*all Disclosures are correct, i.e., their digests are referenced
in the Issuer-signed JWT.*/

As highlighted I have a question about this second bullet point. Can I 
ask why the Disclosures must be referenced in the Issuer-signed JWT 
and not simply ignored if they do not exist in the JWT? There doesn't 
appear to be a security benefit to simply halt and to not verify what 
could otherwise be a valid SD-JWT, as the unbound Disclosures would 
never be processed as part of the SD-JWT verification anyway.


Apologies if this is something that has previously been discussed.

Jacob Ward

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT Redaction Reasons

[Daniel Fett]

At least at the moment I don't think that there is a huge need for such 
a feature. I don't think that we should clutter the existing SD-JWT data 
structures with such information.


If required, it could go into a separate data structure in the SD-JWT, 
for example a list of JSON pointers with a mapping to the respective 
redaction reasons.


-Daniel

Am 18.10.23 um 05:03 schrieb Tom Jones:
That's leaking the existence of PII. That requires permission of the 
subject. I think it's way more complicated than you think.


thx ..Tom (mobile)

On Tue, Oct 17, 2023, 6:20 AM Orie Steele  
wrote:


Hello,

In government documents that feature redaction, it's common for
the redaction to be given a reason.

For example, in the Mueller report, we can see "Harm to Ongoing
Matter", "Personal Privacy", "Investigative Technique", as well as
"IT" and "HOM".

In SD-JWT we see the following:

Case 1

"_sd": [
      "IjCRF...znc", // disclosure hash
      "Qdpt9pL...lhU9UDo" // disclosure hash
]

and

Case 2

{ "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash }

After verification and applying disclosures these annotations are
no longer present.

I wonder if it would be worth allowing a reason for why a holder
might have retained a redaction (or chose not to disclose for a
reason).

Since the payload is committed to by the issuer, this information
would have to be present in the disclosures collection for the SD-JWT.

Here is an example disclosure:

[
  "8UbQ9NZ6xseoDqMW_Bd50A", // salt
  "type", // json object key (always a string)
  [ // json object value
    "VerifiableCredential",
    "ExampleAlumniCredential"
  ]
]

Consider the following strawman syntax for disclosing a redaction
reason:

{
  "disclosure hash" : "Personal Privacy" || "Harm to Ongoing Matter"
}

This allows a UI to map the redaction reason into a presentation
(ui) layer for the issuer secured payload.

Since it's an unsecured object, it can be extended with other
fields at the discretion of the holder or issuer.

However it might be secured by nesting it inside another JWT or
SD-JWT.

It would only slightly complicate the verification logic, you
would need to filter any encoded disclosures by the `ey` prefix,
since they will never be found in the payload, as we know they
will hash differently than array encoded disclosures, which will
be found in the payload.

I'll be giving a presentation on this topic to the W3C Credentials
community group later today, happy to shuttle their reactions back
to this list.

Apologies if this has been discussed previously.

Regards,

OS


-- 



ORIE STEELEChief Technology Officerwww.transmute.industries



___
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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Clarification on SD-JWT verification

[Jacob Ward]

Hello again,

On a similar note to my previous email, could I get some clarity on a step
in the SD-JWT verification process?



*4. If any digests were found more than once in the previous step, the
SD-JWT MUST be rejected.*
Step 4 in Section 6.1 (as shown above) could have multiple meanings in my
opinion:
- The digest was found multiple times (for example in an "_sd" array and as
an array element).
- More than one Disclosure have the same digest.

On first reading of this I assumed that this step only covered the first of
those two cases, but it has been pointed out to me by a colleague that it
could cover both. If it is the case that both cases are covered by this
step, then I think it would be helpful to clarify this in the text.

Cheers,

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

[OAUTH-WG] SD-JWT Verification strictness

[Jacob Ward]

Hello all,

Please let me know if there's a better channel to ask questions and/or
raise issues with the SD-JWT spec.

Currently as part of verification of an SD-JWT the following is stated:

*Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that *

   - *the Issuer-signed JWT is valid, i.e., it is signed by the Issuer and
   the signature is valid, and*
   - *all Disclosures are correct, i.e., their digests are referenced in
   the Issuer-signed JWT.*

As highlighted I have a question about this second bullet point. Can I ask
why the Disclosures must be referenced in the Issuer-signed JWT and not
simply ignored if they do not exist in the JWT? There doesn't appear to be
a security benefit to simply halt and to not verify what could otherwise be
a valid SD-JWT, as the unbound Disclosures would never be processed as part
of the SD-JWT verification anyway.

Apologies if this is something that has previously been discussed.

Jacob Ward
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth