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 <f...@danielfett.de> 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
