Give "JSON document of the SD-JWT processing and verification algorithm" a name

[awoie]

We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the processing and verification algorithm. It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT.

The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/231/files#diff-e750c0958ca10e395b4d3b77bb5aafccc668b4a1a50675dda79a8d90b39a2468R714-R715

We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/194

[awoie]

Perhaps you can also confirm that this result in fact contains things like iss, cnf, exp etc., and would only remove _sd, _sd_alg, ....

[bc-pi]

I was typing the following over in #442 when it closed out from under me in favor of this issue.

By Give " a name here what @awoie means is that it'd be useful to have a name to refer to what we call the "processed SD-JWT payload" that's "passed to the application" here and is really the JSON after verification and processing and replacing _sd and ... occurrences with the real values.

[Sakurann]

why the processed SD-JWT payload is not good enough?

(in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)

[awoie]

why the processed SD-JWT payload is not good enough?

(in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)

I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough.

I'd suggest to add one sentence to https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-09.html#section-8.1, e.g.,

"7. Let xzy be the processed result of the asdf algorithm ..."

... and make xzy a defined term, so it can be referenced. I don't think we can use processed SD-JWT payload from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.

[awoie]

why the processed SD-JWT payload is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)

I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough.

I'd suggest to add one sentence to https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-09.html#section-8.1, e.g.,

"7. Let xzy be the processed result of the asdf algorithm ..."

... and make xzy a defined term, so it can be referenced. I don't think we can use processed SD-JWT payload from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.

Btw. if you call it processed payload, that is fine by me but it should be added to 8.1.

[bc-pi]

(in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)

+ 1000000000% !

[selfissued]

Defining terms is good. Dehydrated/hydrated would be bad. ;-)

[bc-pi]

PR https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/456 has a small addition to sec 8.1 for this