Oliver Terbu

I think this is really useful. This allows people to include blockchain accounts in JOSE objects without name ambiguity. Also +1 for registering in IANA after the CAIP was approved....

Thank you so much! I guess we can close this issue now.

@peacekeeper Thanks for your feedback. The Data Integrity Proof extension cannot be used (in a satisfactory manner) for the following reasons: - We would need to define a new suite...

> According to the spec, `proof` is used to _"detect tampering and verify the authorship"_. Let's use this simple example... We have a VC with a `vc.credentialSubject.id = "did:example:1"`, and...

> Hmm I don't really get it. > > You say you cannot use a Data Integrity Proof extension because you would have to define a new suite and that...

> As a side note, if you want to express equivalence between `did:example:1` and `did:example:2`, then that could be expressed via DID document properties and metadata, e.g. [alsoKnownAs](https://www.w3.org/TR/did-core/#also-known-as), [equivalentId](https://www.w3.org/TR/did-core/#dfn-equivalentid), [canonicalId](https://www.w3.org/TR/did-core/#dfn-canonicalid)....

> > since you said the VP proof is there for protecting against tampering and verifying the authorship of the VP (not the VC and not the binding between the...

> I'm generally in favor of the idea, though I really dislike having OR types in a specification, it makes it really hard to implement properly in a number of...

> > I really dislike having OR types in a specification > > Just spitballing here, but what about this upgrade path: > > V1: `holder` = string V2: `holder`...

> > n if that's backwards-looking and this is forward-looking, whoever works on that section of the Imp Guide should know ab > > Hi, > > I think that...