DID as identifier

[fimbault]

To be seen with SECEVENT WG for sub_ids

I'm also including some questions from the ML (here Tobias).

has any thought been had on how the client instance could communicate additional options around what subject identifier types it supports for cases where the client instance will perhaps be required to conduct additional processing on the artifacts returned by the AS? As an example if the AS chose to identify the subject (End-User) using a DID and wanted to include an additional cryptographic assertion that showed it controls keys appropriately associated to the DID, then the client may have wanted to communicate some information up front in their request to ensure they can perform this additional processing, such as the signature suites it supports and in the context of DIDs potentially which DID methods it is capable of resolving?

[tplooker]

Thanks @fimbault to generalize this beyond DIDs and relate it to your PR #220, there may be a need to communicate more detail about the subject identifier formats that the client instance supports in its request to the AS.

[jricher]

In my opinion (as an individual), we need to walk a very careful line about the complexity we define around end user information like this. Presenting and receiving both identifiers and assertions is, to me, pretty straightforward. Both are self-contained bits of information that are meant to be taken in a presentation context. Moving beyond this, things could get hairy fast.

I personally think it makes a lot of sense to enable this kind of thing, but I'm inclined to think that this kind of more advanced presentation and negotiation would be better as a DID-specific extension, and I'd like to see what that looks like. One of the things that the core protocol needs to be able to do is support more complex extensions without breaking.

[fimbault]

Yes, the first step anyways is to see where SECEVENT lands on with regards to DIDs (just as basic identifiers).

[fimbault]

Some text proposal is required to go forward on this issue.

[agropper]

A DID is a reference to a (typically) public control structure called a DID Document. Because DID Documents are presumed public and therefore easily aggregated and indexed, it's desirable to limit their content to only those structures strictly dependent on control by the DID subject. This includes authentication and encryption keys as well as service endpoints. The service endpoints are the demarcation between the public DID Document and private resources under control of the DID controller.

DID Service Endpoints can be used for most anything but two particular service types stand out: communication (e.g.: an inbox) and authorization (e.g. an authorization server). A communication endpoint expects to handle a resource directly whereas an authorization server endpoint expects to return an access token to a resource. Either the communication or authorization service endpoints can optionally be proxied by a mediator in order to reduce the risk of correlation across multiple service domains.

As end-users to the AS, DID subjects can be either the resource owner or a requesting party. Either way, the DID Document can be an effective way to manage authentication, present claims, and sign requests.

A resource owner could use a DID to authenticate to the policy management endpoint of an AS and to provide a service endpoint for AS requests, warnings and errors. Capabilities issued to the resource owner by a resource server (RS) could be delegated to the AS as part of the policy management process.

A requesting party could use a DID to present claims and sign requests to the AS with the goal of receiving an access token.

When an end-user presents an access token as a capability to an RS, a DID may also be required as a matter of RS policy. The DID might be associated with the end user or with a third-party notary that is part of an audit or accountability process.

Because it is typically pubic, the DID service endpoint considerations for an end-user are tied to the costs of processing unsolicited messages and requests. For example, the service endpoint could expect a refundable deposit to cover processing costs.

[fimbault]

Interesting as an overview of possibilities. There are quite a few implications for implementers, who will need guidance on how to do that in practice.

I'd suggest to also review the difference between public DIDs vs potentially more restricted DIDs (eg. peer, orb, keri).

[agropper]

DIDs like peer, orb, keri avoid the cost and transparency of a public ledger while preserving the self-certifying feature of DIDs. This does not change anything when DIDs are used for authorization and delegation such as the cost of processing unsolicited messages and requests. The public ledgers themselves do not typically "publish" DIDs or DID Documents either but simply provide a root of trust for the authenticity of a self-certifying DID.

The use of any DID and associated assertions incurs a privacy risk to the subject and a cost to either the controller or their delegate. The costs can vary widely across DID methods. Resolution, the process of going from a DID to a DID Document, is only costly to the relying party such as an authorization server. Verifying an assertion through a zero-knowledge proofs, for example, can be designed to shift the cost to the end user or the relying party.

[fimbault]

Yes indeed, my comment was really related to what we mean "typically", especially when there's such a large variety of methods in the wild, some of which might expose the user more than others. It is entirely possible to publish DIDs and their updates, so a bit of guidance as to what we consider good practice might help.

[agropper]

It might be wise to steer clear of the DID method issues. The DID rubrics document I linked above could be enhanced with some GNAP-related points if we have some.

GNAP can provide guidance on how to use service endpoints based on the DID-CORE without any method-specific language.

[fimbault]

I like the idea.

[fimbault]

Closing this issue, as a consequence of secevent update to include DIDs