separate sd-jwt and Disclosures using `.` and not `~`

[Sakurann]

separation between sd-jwt and Disclosures should be ., not ~ for consistency and mental model wise. so <SD-JWT>.<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>, instead of <SD-JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>.

[danielfett]

I guess this depends on the mental model :-)

For me, the SD-JWT is primarily a normal JWT. When sending it, some things (the Disclosures) are attached to it. There needs to be a separator different from the ones in the JWT itself for distinguishing the JWT from the "attachment". So these two would work in that mental model: <SD-JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N> or <SD-JWT>~<Disclosure 1>.<Disclosure 2>.<...>.<Disclosure N>

I assume that your and the devs' mental model is that the whole thing that is being sent is a special form of JWT that consists of four instead of three parts: <Header>.<Payload>.<Signature>.<Attachment> where the Attachment is the ~-separated Disclosures.

That would mean, however, that the whole Combined Format is a special kind of JWT with four parts. I don't see it that way. The Combined Format is just a means of sending a JWT and some extra data.

[danielfett]

Also, isn't it much easier to separate the document by ~ and then to process the individual parts, instead of splitting by . and then re-assembling the JWT?

[Sakurann]

I think the concern was that some libraries will take received string and process everything after the last ‘.’ as a signature, which in SD-JWT case includes disclosures.

---

From: Daniel Fett @.> Sent: Thursday, November 24, 2022 1:53:05 AM To: oauth-wg/oauth-selective-disclosure-jwt @.> Cc: Kristina Yasuda @.>; Author @.> Subject: Re: [oauth-wg/oauth-selective-disclosure-jwt] separate sd-jwt and Disclosures using . and not ~ (Issue #180)

Also, isn't it much easier to separate the document by ~ and then to process the individual parts, instead of splitting by . and then re-assembling the JWT?

— Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauth-wg%2Foauth-selective-disclosure-jwt%2Fissues%2F180%23issuecomment-1326209633&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C350ba78360eb426828d808dace01afac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638048803898080811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lwGYrWXo8sV%2FnLlxtme7cCN37MGG5MpIptAYirOQnnM%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMTNZUYUHYARAKQOZXW3CALWJ43IDANCNFSM6AAAAAASJUPQUY&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C350ba78360eb426828d808dace01afac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638048803898080811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wefrc90v3DXGw0qftPZSFOsxgftEddNbQcan5CTKoCw%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.***>

[danielfett]

I don't understand that. The whole string will fail JWT validation in any case, as it is more than a JWT. Devs need to split it before processing.

[peppelinux]

You assume that the JWT Is signed, a JWT May be encrypted and the Number of values separated by . would be 5

The libraries used to parse a jwt checks the jwt headers to know if It is signed or encrypted and, where needed, also the typ.

Using . would be a pain for the parser libraries (and the implementers). Using a typ like sd+jwt or sd+jwt-disclosure (for an envelope JWT) would be recommended to easy the implementers life. Using an envelope jwt (with holder binding claims in It) would be better because this solution represent a self consistent object that could be also encrypted (bringing uniqueness in its presentation and being hard to be tracked on the wire. Its encrypted format would change during each presentation due to claims nonce/aud/iat/ext).

We have an issue on the envelope format (cryptable) and a PR for the typ header claim.

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/118

Instead of dealing with separation chars I'm in favor of an envelope schema encoded in JWT, signed or encrypted (nested)

[peppelinux]

This issue is also related to this thread

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/114#issuecomment-1193920626

[bc-pi]

IMHO ~ is a more appropriate model.

[danielfett]

Let's discuss in our call later.

Some initial thoughts:

• If we use the ~ format, Giuseppe makes a good point with the number of dots.
• An envelope increases the size of the data that needs to be transferred.
• An envelope also means we need to think about alg=none again in case no signature/encryption is needed.
• It adds two new JWTs that we need to describe and distinguish from existing ones (one JWT at issuance time, one at presentation time)
• How does the envelope and a W3C VP work together?

[bc-pi]

Let's discuss in our call later. +1

[peppelinux]

* An envelope increases the size of the data that needs to be transferred.

Only if you don't have the optional Holder binding attestation, otherwise it would be quite similar in size.

* An envelope also means we need to think about `alg=none` again in case no signature/encryption is needed.

the Holder binding should consider to not use alg=none, otherwise it would be as without the holder binding attestation.

* It adds two new JWTs that we need to describe and distinguish from existing ones (one JWT at issuance time, one at presentation time)

yes, one is the envelope of another, and the first should have a typ claim in the header attesting its scope (combined disclosure)

* How does the envelope and a W3C VP work together?

good question, SD-JWT-Combined-Disclosure and W3C VP are self consistent formats, they should be agnostic and avulse each other. We may use SD-JWT even outside W3C vc-data-model. Anyway the SD-JWT disclosure envelope would be submitted in the W3C VP as it is.

[danielfett]

* An envelope increases the size of the data that needs to be transferred.

Only if you don't have the optional Holder binding attestation, otherwise it would be quite similar in size.

There is a size increase due to the added layer of Base64.

This is an SD-JWT with Holder Binding according to the current draft in the repo:

eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImNBRUlVcUowY21MekQxa3pHemhlaUJhZzBZUkF6VmRsZnhOMjgwTmdIYUEifQ.eyJfc2QiOiBbIk5ZQ29TUktFWXdYZHBlNXlkdUpYQ3h4aHluRVU4ei1iNFR5TmlhcDc3VVkiLCAiU1k4bjJCYmtYOWxyWTNleEhsU3dQUkZYb0QwOUdGOGE5Q1BPLUc4ajIwOCIsICJUUHNHTlBZQTQ2d21CeGZ2MnpuT0poZmRvTjVZMUdrZXpicGFHWkNUMWFjIiwgIlprU0p4eGVHbHVJZFlCYjdDcWtaYkpWbTB3MlY1VXJSZU5UekFRQ1lCanciLCAibDlxSUo5SlRRd0xHN09MRUlDVEZCVnhtQXJ3OFBqeTY1ZEQ2bXRRVkc1YyIsICJvMVNBc0ozM1lNaW9POXBYNVZlQU0xbHh1SEY2aFpXMmtHZGtLS0JuVmxvIiwgInFxdmNxbmN6QU1nWXg3RXlrSTZ3d3RzcHl2eXZLNzkwZ2U3TUJiUS1OdXMiXSwgImlzcyI6ICJodHRwczovL2V4YW1wbGUuY29tL2lzc3VlciIsICJpYXQiOiAxNTE2MjM5MDIyLCAiZXhwIjogMTUxNjI0NzAyMiwgInNkX2RpZ2VzdF9kZXJpdmF0aW9uX2FsZyI6ICJzaGEtMjU2IiwgImNuZiI6IHsiandrIjogeyJrdHkiOiAiUlNBIiwgIm4iOiAicG00Yk9IQmctb1loQXlQV3pSNTZBV1gzclVJWHAxMV9JQ0RrR2dTNlczWldMdHMtaHp3STN4NjU2NTlrZzRoVm85ZGJHb0NKRTNaR0ZfZWFldEUzMFVoQlVFZ3BHd3JEclFpSjl6cXBybWNGZnIzcXZ2a0dqdHRoOFpnbDFlTTJiSmNPd0U3UENCSFdUS1dZczE1MlI3ZzZKZzJPVnBoLWE4cnEtcTc5TWhLRzVRb1dfbVR6MTBRVF82SDRjN1BqV0cxZmpoOGhwV05uYlBfcHY2ZDF6U3daZmM1Zmw2eVZSTDBEVjBWM2xHSEtlMldxZl9lTkdqQnJCTFZrbERUazgtc3RYX01XTGNSLUVHbVhBT3YwVUJXaXRTX2RYSktKdS12WEp5dzE0bkhTR3V4VElLMmh4MXB0dE1mdDlDc3ZxaW1YS2VEVFUxNHFRTDFlRTdpaGN3IiwgImUiOiAiQVFBQiJ9fX0.rV7UrCdR64tA-G0_rjqYaKYukzIJi1RPgvX4eGSk5HHYWPl3-j8LEUnePSX-OlQXe5RgsOqPo9DCj7-CLvKKxam-PbEQZurYX4qEzFyCJUOTMbOTQSLdsSe9tf1pD_yIrJhIscjXiq_mtJww_abdT8fIiS4h8kir2ClZifjNnLkKzqceVgrCipjbt76iZ6m_DGO2jFhU8Zzrat3UZALacw4fRD0l5MGIGHdQcipouhhvVBnWyl6lH8gtcOFMl4YSSoWP9ytFLoahCSRrF5mCo1tSFg3I70v4mk2U59GfcU94GaEB0q6uF__fbEmOClUPX9yOrYryeqjJR0bBRUK_NA~WyIweEd6bjNNaXFzY3RaSV9PcERsQWJRIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJxUVdtakpsMXMxUjRscWhFTkxScnJ3IiwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyIzanFjYjY3ejl3a3MwOHp3aUs3RXlRIiwgImdpdmVuX25hbWUiLCAiSm9obiJd~eyJhbGciOiAiUlMyNTYiLCAia2lkIjogIkxkeVRYd0F5ZnJpcjRfVjZORzFSYzEwVThKZExZVHJFQktKaF9oNWlfclUifQ.eyJub25jZSI6ICJYWk9VY28xdV9nRVBrbnhTNzhzV1dnIiwgImF1ZCI6ICJodHRwczovL2V4YW1wbGUuY29tL3ZlcmlmaWVyIiwgImlhdCI6IDE2NjkxOTM3MDR9.Y5xmEip11zOmZR1xvgdbi9IanCNQ4ODJDNW8JKpNvBNOCP2j_DbsCMoYAv6RrOYSzEPZplJ8MlfiZzC9ldcvByiAjWeJbMStZ1vf_K-AJnyNLwnA_v0zVwA0d8rkrIqSQomS5-GqN3zJtUpl2BslLa799UpdCwg7Rfow2wFSfL6S2J9j2mb5Q5UVxTcU27OXcLUn0aN8slIr5AmYd-EcoAqWe8feV6plkHnYac6M9LclgInE5IzwFJTezNmERocADNB7ZGGoy9FzdNdepjnzjFVjazYT0gtR0XgOg5epZoTeOrJwdYT0d5VFwO4ep9_Q591bxnNHfPbr5AhdYALCGg

It has ~2440 chars.

With an envelope, the envelope JWT is as follows (quickly put together in jwt.io):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZC1qd3QiOiJleUpoYkdjaU9pQWlVbE15TlRZaUxDQWlhMmxrSWpvZ0ltTkJSVWxWY1Vvd1kyMU1la1F4YTNwSGVtaGxhVUpoWnpCWlVrRjZWbVJzWm5oT01qZ3dUbWRJWVVFaWZRLmV5SmZjMlFpT2lCYklrNVpRMjlUVWt0RldYZFlaSEJsTlhsa2RVcFlRM2g0YUhsdVJWVTRlaTFpTkZSNVRtbGhjRGMzVlZraUxDQWlVMWs0YmpKQ1ltdFlPV3h5V1RObGVFaHNVM2RRVWtaWWIwUXdPVWRHT0dFNVExQlBMVWM0YWpJd09DSXNJQ0pVVUhOSFRsQlpRVFEyZDIxQ2VHWjJNbnB1VDBwb1ptUnZUalZaTVVkclpYcGljR0ZIV2tOVU1XRmpJaXdnSWxwclUwcDRlR1ZIYkhWSlpGbENZamREY1d0YVlrcFdiVEIzTWxZMVZYSlNaVTVVZWtGUlExbENhbmNpTENBaWJEbHhTVW81U2xSUmQweEhOMDlNUlVsRFZFWkNWbmh0UVhKM09GQnFlVFkxWkVRMmJYUlJWa2MxWXlJc0lDSnZNVk5CYzBvek0xbE5hVzlQT1hCWU5WWmxRVTB4YkhoMVNFWTJhRnBYTW10SFpHdExTMEp1Vm14dklpd2dJbkZ4ZG1OeGJtTjZRVTFuV1hnM1JYbHJTVFozZDNSemNIbDJlWFpMTnprd1oyVTNUVUppVVMxT2RYTWlYU3dnSW1semN5STZJQ0pvZEhSd2N6b3ZMMlY0WVcxd2JHVXVZMjl0TDJsemMzVmxjaUlzSUNKcFlYUWlPaUF4TlRFMk1qTTVNREl5TENBaVpYaHdJam9nTVRVeE5qSTBOekF5TWl3Z0luTmtYMlJwWjJWemRGOWtaWEpwZG1GMGFXOXVYMkZzWnlJNklDSnphR0V0TWpVMklpd2dJbU51WmlJNklIc2lhbmRySWpvZ2V5SnJkSGtpT2lBaVVsTkJJaXdnSW00aU9pQWljRzAwWWs5SVFtY3RiMWxvUVhsUVYzcFNOVFpCVjFnemNsVkpXSEF4TVY5SlEwUnJSMmRUTmxjeldsZE1kSE10YUhwM1NUTjROalUyTlRsclp6Um9WbTg1WkdKSGIwTktSVE5hUjBaZlpXRmxkRVV6TUZWb1FsVkZaM0JIZDNKRWNsRnBTamw2Y1hCeWJXTkdabkl6Y1haMmEwZHFkSFJvT0ZwbmJERmxUVEppU21OUGQwVTNVRU5DU0ZkVVMxZFpjekUxTWxJM1p6WktaekpQVm5Cb0xXRTRjbkV0Y1RjNVRXaExSelZSYjFkZmJWUjZNVEJSVkY4MlNEUmpOMUJxVjBjeFptcG9PR2h3VjA1dVlsQmZjSFkyWkRGNlUzZGFabU0xWm13MmVWWlNUREJFVmpCV00yeEhTRXRsTWxkeFpsOWxUa2RxUW5KQ1RGWnJiRVJVYXpndGMzUllYMDFYVEdOU0xVVkhiVmhCVDNZd1ZVSlhhWFJUWDJSWVNrdEtkUzEyV0VwNWR6RTBia2hUUjNWNFZFbExNbWg0TVhCMGRFMW1kRGxEYzNaeGFXMVlTMlZFVkZVeE5IRlJUREZsUlRkcGFHTjNJaXdnSW1VaU9pQWlRVkZCUWlKOWZYMC5yVjdVckNkUjY0dEEtRzBfcmpxWWFLWXVreklKaTFSUGd2WDRlR1NrNUhIWVdQbDMtajhMRVVuZVBTWC1PbFFYZTVSZ3NPcVBvOURDajctQ0x2S0t4YW0tUGJFUVp1cllYNHFFekZ5Q0pVT1RNYk9UUVNMZHNTZTl0ZjFwRF95SXJKaElzY2pYaXFfbXRKd3dfYWJkVDhmSWlTNGg4a2lyMkNsWmlmak5uTGtLenFjZVZnckNpcGpidDc2aVo2bV9ER08yakZoVThaenJhdDNVWkFMYWN3NGZSRDBsNU1HSUdIZFFjaXBvdWhodlZCbld5bDZsSDhndGNPRk1sNFlTU29XUDl5dEZMb2FoQ1NSckY1bUNvMXRTRmczSTcwdjRtazJVNTlHZmNVOTRHYUVCMHE2dUZfX2ZiRW1PQ2xVUFg5eU9yWXJ5ZXFqSlIwYkJSVUtfTkEiLCJkaXNjbG9zdXJlcyI6WyJXeUl3ZUVkNmJqTk5hWEZ6WTNSYVNWOVBjRVJzUVdKUklpd2dJbUZrWkhKbGMzTWlMQ0I3SW5OMGNtVmxkRjloWkdSeVpYTnpJam9nSWpFeU15Qk5ZV2x1SUZOMElpd2dJbXh2WTJGc2FYUjVJam9nSWtGdWVYUnZkMjRpTENBaWNtVm5hVzl1SWpvZ0lrRnVlWE4wWVhSbElpd2dJbU52ZFc1MGNua2lPaUFpVlZNaWZWMCIsIld5SnhVVmR0YWtwc01YTXhValJzY1doRlRreFNjbkozSWl3Z0ltWmhiV2xzZVY5dVlXMWxJaXdnSWtSdlpTSmQiLCJXeUl6YW5GallqWTNlamwzYTNNd09IcDNhVXMzUlhsUklpd2dJbWRwZG1WdVgyNWhiV1VpTENBaVNtOW9iaUpkIl0sIm5vbmNlIjoiYWJjZCIsImF1ZCI6Imh0dHBzOi8vZXhhbXBsZS5jb20ifQ.0T47qH5qwRsWiAVN1JQVdhWAFfD4BIgDCSoJmapd92M

This has ~2700 chars.

* An envelope also means we need to think about `alg=none` again in case no signature/encryption is needed.

the Holder binding should consider to not use alg=none, otherwise it would be as without the holder binding attestation.

How would you do HB with an envelope but without alg=none? Just a JSON document?

* It adds two new JWTs that we need to describe and distinguish from existing ones (one JWT at issuance time, one at presentation time)

yes, one is the envelope of another, and the first should have a typ claim in the header attesting its scope (combined disclosure)

Ignoring the inner SD-JWT, two envelopes are needed: One during issuance (no Holder Binding, but maybe encrypted?), one during presentation (with optional HB).

[peppelinux]

There is a size increase due to the added layer of Base64.

thank you for this empiric analysis, we have roughly the 10% of additional weight using an envelope JWT.

The benefit is that an envelope JWT can be encrypted and be tracking resistant on the wire (in short/raw RF links), because the sequence of the bytes would always be different (thanks to variable claims like iat, exp, nonce ...). The disclosure object in the raw concatenation we already have are transmitted in plain b64 encoded text. The potential, and optional, encryption of the envelope JWT (sd-disclosure+jwt or whatever typ) wouldn't be a useless and exceeding security device I believe, it would concretely protect the confidentiality at the data format level.

How would you do HB with an envelope but without alg=none? Just a JSON document?

Not sure to get this, I'm sorry. I mean that I wouldn't support alg=none for HB.

Ignoring the inner SD-JWT, two envelopes are needed: One during issuance (no Holder Binding, but maybe encrypted?), one during presentation (with optional HB).

Well, probably it would be a necessary work of normalization between the two flows and I agree. For the issuance the holder binding would be in the inned SD-JWT (cnf, for example). But probably I'm missing something, my excuses again.

[danielfett]

There is a size increase due to the added layer of Base64.

thank you for this empiric analysis, we have roughly the 10% of additional weight using an envelope JWT.

The size increase should be (in the generalized case) around 33%.

The benefit is that an envelope JWT can be encrypted and be tracking resistant on the wire (in short/raw RF links), because the sequence of the bytes would always be different (thanks to variable claims like iat, exp, nonce ...). The disclosure object in the raw concatenation we already have are transmitted in plain b64 encoded text. The potential, and optional, encryption of the envelope JWT (sd-disclosure+jwt or whatever typ) wouldn't be a useless and exceeding security device I believe, it would concretely protect the confidentiality at the data format level.

I do see the benefit of the encryption, but I think that this should be handled by a lower layer, e.g., BLE encryption. In many cases, there is no benefit from the encryption or signing. In fact, if BLE is used, the 33% increase in size is certainly not desirable.

How would you do HB with an envelope but without alg=none? Just a JSON document?

Not sure to get this, I'm sorry. I mean that I wouldn't support alg=none for HB.

Can you please provide a full example of what you imaging an SD-JWT issuance and presentation with and without HB look like for the benefit of the discussion? I'd like to avoid that we're talking about different things here.

Ignoring the inner SD-JWT, two envelopes are needed: One during issuance (no Holder Binding, but maybe encrypted?), one during presentation (with optional HB).

Well, probably it would be a necessary work of normalization between the two flows and I agree. For the issuance the holder binding would be in the inned SD-JWT (cnf, for example). But probably I'm missing something, my excuses again.

Again, a full example would be helpful to continue this discussion.

[peppelinux]

I do see the benefit of the encryption, but I think that this should be handled by a lower layer, e.g., BLE encryption. In many cases, there is no benefit from the encryption or signing. In fact, if BLE is used, the 33% increase in size is certainly not desirable.

this implies that the security of the data format is dependant of the transport protocol. I'd prefer to keep it self-consistent also in this aspect

Can you please provide a full example of what you imaging an SD-JWT issuance and presentation with and without HB look like for the benefit of the discussion? I'd like to avoid that we're talking about different things here.

true, I should have done that sooner!

Here a Combined issuance:

{
  "alg": "RS256", 
  "kid": "TGBKFdOKy5t-1m2Km4X22n7DEj553yjGJVdprbOjR6c",
  "typ": "sd+jwt-combined-issuance"
}
.
{
  "iss": "https://example.com/issuer",
  "sub": "subject-id",
  "iat": "unix-timestamp",
  "aud": "holder-id",
  "nonce": "that-unique-and-random-sequence",
  "sd_jwt": $sd-jwt,
  "sd_disclosures": {
    "30jdaA9OfGpa3Tj5XJbtWiVrl4i66my26mOnbIuwY0w": ["Lz-3RoXunbH2oLZXNRbqLw", "number", "154554"],
    ... others ...
  }
}

Where $sd-jwt is

{
  "alg": "RS256", 
  "kid": "TGBKFdOKy5t-1m2Km4X22n7DEj553yjGJVdprbOjR6c",
  "typ": "sd+jwt"
}
.
{
  "_sd": [
    "UxYjx8bYA86RGAHOjRjntztJ16doIL9tAFREFeQCKz0"
  ],
  "verified_claims": {
    "verification": {
      "_sd": [
        "OKbpoO_RGyeF1FP_X4RI67ytOW5OO5pj8iAEHPPmGzQ"
      ],
      "trust_framework": "eidas",
      "evidence": [
        {
          "_sd": [
            "DwtOtYlPczP3j0CAGmwK_sG1PS15BePEWennozJtnc4",
            "N5X-cmduA_hEiG-2-TFHWlYFPmuPAhgMSDAd5-_0ANw"
          ],
          "document": {
            "_sd": [
              "30jdaA9OfGpa3Tj5XJbtWiVrl4i66my26mOnbIuwY0w",
              "Fsu1XL9NW1tHVpytr44jFbXwdhX1avNlRArOzRRj6FQ",
              "PPzuOzIrbneVJ49-K3zgqOPDJvFgbipGcU1Psg2BqPY",
              "wnXuBaY3ZVHy7qb8zhyVqGjs5ZywuwfDxJ3pIc1vHQo"
            ],
            "issuer": {
              "_sd": [
                "S-K8XHQ5-TipWeWHZNcKLe4gyqoTW8QPl6XXdmnBPiI",
                "VBsVXxKHbC7-6dVZcdFg9kU7yCNsPWob4bDcVbZB4-w"
              ]
            }
          }
        }
      ]
    },
    "claims": {
      "_sd": [
        "9C3BrCMDx2zsqn9IhN7siBJXSyZvvJoDYzGsyHhhnZU",
        "QVtNjGpLtd7NpJgfjBTMhKwwef4EE2VuEE-jBKQJueA",
        "zXwogmNL4aJrhL7OikfJCpDYpPNSA1SyFciDIcWP14k"
      ]
    }
  },
  "iss": "https://example.com/issuer",
  "iat": 1516239022,
  "exp": 1516247022,
  "sd_digest_derivation_alg": "sha-256"
}

For combined presentation the same formula of the issuance but with:

• iss: different, that's the holder
• sub: a pseudonymization issued by the holder is possibile here (additional feature)
• aud: RP entity id
• nonce: another-one
• sd_jwt: as it is
• sd_disclosure: what the end-users decides to disclose

regarding the header of the presentation, the typ would be sd+jwt-disclosure.

May we add the JWT envelopes keeping at the same time the raw-combined approach with string concatenation in the draft for embedded implementations where size matters? The typ and the ~ help also in this, to understand which kind of format we're dealing with

[danielfett]

Thank you! In your example above, the disclosure is plain JSON, which will require canonicalization for reproducible hashes. Is that intentional?

[peppelinux]

Thank you! In your example above, the disclosure is plain JSON, which will require canonicalization for reproducible hashes. Is that intentional?

good point. I think that we can adopt base64 encodings instead of plain json array if you agree.

an important aspect of the proposed new structure is the mapping between the digest and the disclosure (which would be encoded in base64 following our last comments). This better explains the mapping between hashed _sd and related disclosure

also the disclosure would be resistant to reply attacks by default

[danielfett]

This mapping is a bit dangerous - it allows a verifier to extract the claim contents without verifying the hash. This means that a malicious holder can modify the disclosures and a verifier might not notice it. In the current draft, this mapping is omitted on purpose - it forces verifiers to hash before they can use the contents.

[peppelinux]

This mapping is a bit dangerous - it allows a verifier to extract the claim contents without verifying the hash. This means that a malicious holder can modify the disclosures and a verifier might not notice it. In the current draft, this mapping is omitted on purpose - it forces verifiers to hash before they can use the contents.

well, in the real world nothing prevents that an implementation simply decodes a JWT without verify its signature and so on, but I got the point and I agree with your strategy. So the mapping can be abandoned and a json array would be applied.

[danielfett]

I thought about this a little more and I'm still convinced we're entering a whole new protocol layer with the envelope.

With the current proposal, we have:

• Two byte-level interoperable string formats as output of Issuer and Holder and input to Holder and Verifier.
• These strings can be packed into other objects as necessary.

With the envelope we have:

• Another JWT that we need to explain and distinguish from the inner SD-JWT.
• Fuzzy boundaries between the contents: E.g., we may have two iat claims.
• A size increase due to double base64 encoding.
• This may be my main concern: we default to a JWT for presentation, so if we want to skip holder binding, it's either:
  • a deviation from the default by using a base64 encoded JSON, or
  • a JWT with alg=none.

The only real advantage that I see for the envelope is the encryption.

What about this?

• Issuance combined format remains as-is, i.e., <SD-JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N> (<SD-JWT>~<Disclosure 1>.<Disclosure 2>.<...>.<Disclosure N> would be fine for me as well)
• Presentation combined format remains as-is, but
• we highlight that the implementers that want to do holder binding using an envelope JWT can do so, and
• implementers that need encryption should use an outer JWT.

We will define a claim, e.g., _sd_jwt_presentation that contains the presentation combined format in the envelope JWT.

[peppelinux]

we highlight that the implementers that want to do holder binding using an envelope JWT can do so

Ok

implementers that need encryption should use an outer JWT.

Ok

We will define a claim, e.g., _sd_jwt_presentation that contains the presentation combined format in the envelope JWT.

Fair enough!

[danielfett]

I tried to capture the results of this discussion in a PR. Please review!

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/184

[danielfett]

This has been addressed with PR #184. We agreed that there is no need for further discussion on the initial suggestion (. vs. ~). I'll therefore close this issue.