WIP: v1.2 - Moving towards a stronger model for named actor signatures

[tweeddalex]

• I have read the CLA Document and I hereby sign the CLA.

---

Hey all,

I've been working on a fork draft of the spec which I'm provisionally labelling v1.2, and want to raise the main alteration here before I finish and propose the draft.

1. Named Actor DIDs and associated signatures

@scouten-adobe's presentation on why the Claims Aggregation model is preferable to using self-signed credentials or presentations still remains very valid, due to the audience that this is being positioned towards. No Named Actor wants to know what a DID is, and no Named Actor wants to manage a public/private key pair themselves.

However, I think that we can reach a better compromise than the existing Claims Aggregation model, which is better future proofed for an ecosystem where:

• The Named Actor may want to collect assertions from multiple sources, aggregated around a particular identifier
• Relying parties should still be able to validate that an identity assertion has been signed by a particular Named Actor, even if their signing key is custodied by the Claims Aggregator

The core shift in v1.2 would be to revisit the Verifiable Presentation model, but where the Claims Aggregator remains in custody of the Named Actor's keys. This achieves the benefits in terms of user experience for the Named Actor, whereby they don't need to know they have a set of keys or an identifier, but can also sign claims through the Claims Aggregator as a proxy. In the future, this would also enable a named actor to use multiple Claims Aggregators and export/import their keys between Claims Aggregators.

2. did:key for Named Actors

Here, I would propose that each Named Actor is actually provided a did:key that remains under the custody of the Claims Aggregator. This improves from the current draft, where the Named Actor is identified only by an Adobe Connected Identities URL (e.g. "did:web:connected-identities.identity.adobe.com:user:jsadkfnaksdnj").

This did:key would not provide "autonomous" signing capability for the Named Actor, but it would show that all Presentations of Aggregated Claims were initiated by the account that the Named Actor controls access over.

As such, did:web would remain the core DID method for issuers, and did:key would become the core DID method for Named Actors.

Please see the example of a Cred here (there's a toggle for the JSON), where you can see that this Named Actor has a did:key. In our Creds example, the user is able to share presentations of Creds without needing to know they have a set of keys: https://profile-staging.creds.xyz/share/zkp-mesa-scd

3. Credentials issued by the Claims Aggregator for the claims from the Identity Provider

I propose that once a user connects to various identity providers, the data that is pulled from the Identity Provider is wrapped into a Verifiable Credential and issued to the did:key address of the Named Actor by the Claims Aggregator (acting as an issuer).

Here, the Named Actor can accumulate a set of Verifiable Credentials from different sources, which then later on, it can use to sign content credentials following the existing spec pathway.

This standardizes the way that Claims Aggregators handle the storing and management of data from Identity Providers, converting it into verifiable credential format and signing it using their DIDs.

4. Named Actor Verifiable Presentations

The Named Actor, now with a collection of credentials they hold in their Claims Aggregator account, will be able to bundle these claims together and indicate that they want to sign content. The Claims Aggregator, as it custodies the did:key for the Named Actor, will still perform the signature and compile the presentation on behalf of the Named Actor, however, now this is a much stronger signal that the Named Actor consented and actively actioned this process.

Future benefits of this switch

• Identifying a user with a did:web + Connected Identities user name (as currently in the spec), ties that user to a specific Claims Aggregator, which can be improved upon
• Having did:key addresses for the users means that Claims Aggregators can aggregate credentials from different sources in the future, if they are issued to that did:key addrses - acting as a custodial wallet, rather than just an aggregator
• Individual credentials can be revoked here (as each Identity Provider connection issues its own credential to the Named Actor), without invalidating the entire Aggregated Presentation or Credential. This enables content to remain trustworthy, even if one of the credentials embedded in it has been revoked (for a reason such as someone changing their social media handle).

[ankurdotb]

This is a good set of ideas. The only thing I would change is not to assume there's a singular did:key for Named Actors. They may have one or more did:key's associated with them, since they might establish pairwise relationships with the different Claim Aggregators. On being asked to present, they may choose one or many of their did:key's to generate the presentations. IMO that would be fine and offer people a choice. The spec doesn't need to be prescriptive about the number of DIDs that Named Actors or Claim Aggregators have.

[puhley]

I made a comment during the meeting that having Claim Aggregators being an "all eggs in the same basket" model for storing people's keys and identity will run into a huge issue the first time there is a data breach with a Claims Aggregator. This sort of model will put a huge target on Claim Aggregators. Once there is a successful breach, there would need to be a huge revocation of certificates.
We also can't assume that every Claim Aggregator is an organization faithly working towards the benefit of everyone. Due to different legal jurisdictions, in different countries, with different levels of human rights, it could be a potential harm for a person's identity to be able to be subpoenaed/stolen by a country's government. Keep in mind that these identities might be reporters doing at-risk field reporting.
Therefore, I believe it is a large oversimplification to state that, "No Named Actor wants to know what a DID is, and no Named Actor wants to manage a public/private key pair themselves." If I am a journalist doing at-risk field reporting, then my life is dependent on the security of that key.

[bumblefudge]

one or more did:key's associated with them, since they might establish pairwise relationships with the different Claim Aggregators.

what worries me most about the Claims Aggregator relationship is that we are using a necessarily long-term, non-portable OOB relationship to make up for the lack of a long-term, non-portable identifier, i.e. locking subjects into long-term contracts/SLAs with those aggregators, particularly if it's just a a non-rotatable did:key custodied by the aggregator-provider. at least with did:webvh or did:plc the identifier outlives a service-provider migration (although in both cases the resolvability of dids is a little underspecified/unknown)...

[scouten-adobe]

@tweeddalex and Andrew D to lead discussion for 1.2 milestone. Goals are to integrate more seamlessly with existing VC and VP standards and also to more deeply document the named actor's role in the production of the content.

[bumblefudge]

@andrewDworschak