Jer Miller

On the last call @tplooker brought up handling of the presentation header when there are multiple signatures from different suites. My suggestion is that there is only a single presentation...

For the different categories of multisig (listed above): could we used the word "_conjoined_" to describe when the issuers are aware of and witnessing each other's issuance (in a verifiable...

After mulling on this a LOT, I'm currently thinking that support for multiple issuers/proofs/etc is always most properly done by adding a JPA specifically to address the needs and underlying...

I believe the flexibility will be there to do this within an algorithm definition. For example, use an `alg="BBS-MULTI"` that is just an extension of the BBS alg that supports...

> potentially removing the more flexible blind sign functionality. This would invalidate private linking use-cases, where the holder wants to link different credentials together from multiple issuers without revealing the...

> do you mean general private linking use-cases? I was speaking to linking of multiple different credentials (by using the same link secret, blinded to multiple issuers). > I think...

I completely understand your comments here, I'm not in love with the coupled jwk-lyt approach either so hopefully we can find a happier path without adding too much complexity. Consider...

The current draft has switched to a simpler flat `claims` array instead of a layout. It also adds a `cid` with a specific digest value such that externally defined claims...

Proposing to add to draft, include note that it may become own spect.

I think we'll likely need a separate registry where we re-register all the existing JWT claims and explain any capabilities added by JWP (such as using predicate proofs). The one...