Jer Miller

While it's not as ideal from a parsing perspective, Option 3 is I believe the correct abstraction. The challenge is really in the interface to the JWA, the implementing algorithm...

There'll be some updates in other issues/threads here about the layout and claims mapping which would make your next step drastically simpler. > I also don't love that I had...

This is an excellent privacy consideration, though I would expect it to be in the presentation exchange layer so that it applies unilaterally to both the format and to any...

The alg value has to be the same during issuance and presentation, it is intended to _only_ represent which cryptographic subsystem is used to operate on the given JWP. There...

The hard reality here is that it's simply not possible to actually secure any type of distinction between the issuance context and the presentation context outside of what the algorithm...

It is the application's responsibility to track the context, if it was received in a signing context, or if it was received in a presentation one. An algorithm may know...

This is an excellent thread that has had me really thinking, I'm now thinking along the same lines, that a presented JWP needs an additional header element that is generated...

> So I think to answer your question around how a BBS proof would map conceptually to this proposal the VERIFY_HEADER would just be the presentation message? Yep, that's exactly...

> Can someone provide a concise description of what the two different headers would be for and would contain (and would not contain)? The names I'm using for each are...

The example header would look more like: ```json { "iss": "did:example:1234", "vc": { "type": ["VerifiableCredential", "BasicCredential"], }, "claims": [ "sub", "nbf", "exp", "jti", "family_name", "given_name", "email", "age" ], "typ": "JPT",...