Allow for machine readable identity assurance documents

[schmudde]

This recommendation is taken within the context of the v1.0 specification. From the v1.0 readme:

Authorized Agents involved in the Data Rights Protocol Network will act within a closed trust network for the forseeable future. Implementers will work with minimal technical trust mechanisms and instead rely on an operating agreement between implementers deploying this protocol in production

This closed network for Authorized Agents is currently manged by agents.json. It looks something like

{"id": "string",
 "name": "string",
 "verify_key": "string",
 "web_url": "https://example.com",
 "technical_contact": "alice@example.com",
 "business_contact": "bob@example.com",
 "identity_assurance_url": "https://example.com/identity-assurance"}

The identity assurance claims in agents.json are meant to be human readable (HTML or PDF) but the current DRP Readme mentions OpenID Connect for Identity Assurance (OIDC4IDA). I argue that a machine-readable discovery document that makes claims about our verified emails would be broadly useful for Authorized Agent actions (even outside of DRP).

A machine readable, OIDC compatible identity_assurance_url would point to a discovery endpoint at https://example.com/.well-known/openid-configuration. The information therein would conform to the OpenID Connect Discovery Section 3. OpenID Provider Metadata claims_parameter_supported and claims_supported.

{"issuer": "https://example.com",
  "claims_parameter_supported": true,
  "claims_supported": ["sub", "iss", "auth_time", "name", "given_name", "family_name", "email", "email_verified"],

Adding the ODIC extension, OpenID Connect for Identity Assurance 1.0 Section 8. OP metadata, more sophisticated claims can be made:

The OP advertises its capabilities with respect to verified claims in its openid-configuration (see [OpenID-Discovery]) using the following new elements:

• trust_frameworks_supported
• claims_in_verified_claims_supported: All claims supported within verified_claims, claims that are not present in this array shall not be returned within the verified_claims object.
• evidence_supported: Members of this array should only be the types of evidence supported by the OP in the evidence element.
• documents_supported Required when evidence_supported contains document.

Thus a more sophisticated set of claims may look like this:

{"issuer": "https://example.com",
 "claims_parameter_supported": true,
 "claims_supported": ["sub", "iss", "auth_time"],
 "trust_frameworks_supported":["nist_800_63A"],
 "evidence_supported": ["document", "electronic_record", "vouch", "electronic_signature"],
 "documents_supported": ["idcard", "passport", "driving_permit"],
 "claims_in_verified_claims_supported": ["given_name", "family_name", "birthdate", "place_of_birth", "nationalities", "address", "name", "given_name", "family_name", "email", "email_verified"]}

These verified claims could be meaningful in the current closed DRP network; Covered Businesses would know what data may be verified by an Authorized Agent.

But this lays the groundwork for the Covered Business to understand which specific claims are verified. Such a strategy provides the first automated solutions for the in_progress → need_user_verification state, even within then DRP closed network. Again from the current DRP Readme:

This need_user_verification has not been implemented or explored by any DRP implementers. If the need for this arises in your implementation, please reach out to DRP protocol developers to work towards implementation and improvement. See GitHub issue #52.

Adoption of DRP could quickly lead to covered businesses requesting real name or address verification before deletion. But even if Authorized Agents have verified information on-hand, there is no way to express what specific information is verified for a specific person.

Authorized Agents could provide an optional website or endpoint where Covered Business would query using a hash value (based on the existing DRP verify_key) to see what information the specific individual has verified.

The response of such a query would follow the OIDC4IDA standard. In the interest of brevity, I will not include that example in this GitHub issue.

Such conformance also lays the rails for a federated DRP network in the future.

This issue is somewhat ambiguous because even partial implementation could provide benefits for both Covered Businesses and Authorized Agents.