search

decentralized-identity / interoperability

The archive and information hub for the cross-community interoperability project. Focus is on education and familiarity for various efforts across multiple groups for interoperable decentralized identity infrastructure.
https://identity.foundation/interop/
Apache License 2.0
92 stars 19 forks source link

Adopt Issuer Server Infrastructure #6

Closed OR13 closed 5 years ago

OR13 commented 5 years ago

Publishing the Issuer DID on the Issuer Website

In order to keep things simple, the issuer needs a DID to be accessible via their domain (issuer-corp.example.com)

It is also possible to use webfinger for this purpose, see this link:

https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/

If we wish to provide an email for the issuer, we can used this method to obtain a did for it from the server:

acct:issuer@issuer-corp.example.com

If not we can simply publish the DID via http, and html.

Authenticating a subject

The drawing suggest that the user is already signed in.

If we wish for each credential claim request for a DID to be authenticated, the server needs to generate a unique challenge with expiration on page load, and the subject needs to sign and return this challenge before it expires with a key linked in their DID document.

There is a lot of usability opportunities here, the key is that the challenge format and signature suites be agreed upon.

Issuing the credential

The issuer server can create and sign a claim about the DID subject once it has authenticated the DID. All that is needed is the credential format, and a signing key linked in the Issuer DID document, which can be setup in advance.

The issuer server needs access to the signing key or needs to proxy requests to the issuer. For the sake of simplicity we should embed the key to reduce proxying requests (save for future work / DIDComs integration).

Accessing a credential.

The credential can either be a JWT bearer token, or it can be a JWT with a self referencing URL. Instead of integrating support for the various different wallets, it might be best to start with a simple URL format.

OR13 commented 5 years ago

Authentication of the DID Subject should be via Bearer Token JWT, issued by the Issuer Server.

The issuer server will implement a simple challenge response flow over http if no other DID Auth Methods are suggested.

The format of the challenge response flow will be ES256K JWT.

csuwildcat commented 5 years ago

IMO, we should use Identity Hubs vs Activity Pubs, because of how architecturally stunted the Activity Pub project is. If we're talking about a conduit for discovery of potential creds to be issued, requests of issuance with proofs, and delivery of issued material, Identity Hubs were made to serve as the component to do so.

csuwildcat commented 5 years ago

As for linking a DID to a web domain, I would suggest two mechanisms:

  1. DNS URI entry with embedded DID signature
  2. Well-Known (ex: ./well-known/did) endpoint with signed entries that link to DIDs

@peacekeeper and I have been working on this a bit, and would be happy to pitch in.

OR13 commented 5 years ago

@csuwildcat Thanks, regarding Identity Hubs I think we can get away with supporting them for claim retrieval assuming there is a REST API standard for accessing them (with or without auth).

Can you link me to how I can request a claim from a hub according to the spec that might look like this:

https://hub1.example.com/issuer/:issuerDID/credentials/:subjectDID?type=EducationCert

I'm sure this format is not correct, but if we can document what the REST interface for "get a credential for a subject from an issuer", that would make hub support easier to integrate. I don't think we should plan to support full identity hub apis, just the minimum needed for the Edu flow.

As I understand it, we need to be able to:

  1. Add a Credential to the Issuer's Hub.
  2. Get a Credential from the Issuer's Hub
  3. Maybe support Authentication for 1 & 2.

The more references / links to code that can do this, the easier it is to adopt hubs.

Regarding the DID for the domain, I'm in favor of adopting ./well-known/did. I will create a standalone ticket for that so this thread can be preserved for handling the harder parts of reading and writing credentials wrt the issuer server.

Tracking of DID Registeration for Issuer and Verifier Web Servers:

https://github.com/decentralized-identity/interop-project/issues/7

csuwildcat commented 5 years ago

In terms of how you would get a claim from a Hub, we are thinking of a bit different request structure. You can still use HTTP as one of the methods, but the request will be something like:

Generate a POST request to the following to hub.example.com/did:foo:123:

{
  "@context": "https://schema.identity.foundation/0.1",
  "@type": "ObjectQueryRequest",
  "iss": "did:foo:123abc"
  "query": {
      "interface": "Collections",
      "context": "https://www.w3.org/2018/credentials/v1",
      "type": "EducationCert"
  }
}

The request is fully contained in the object, and the target interface where all objects live (including credentials).

OR13 commented 5 years ago

The example code here seems to indicate that read and write for hubs would work:

https://github.com/decentralized-identity/hub-sdk-js/blob/master/src/example.ts

If we were to take the hub approach is this how it would work?:

  1. https://hub.identity.foundation is an Identity Hub for Interop Project DIDs.
  2. https://issuer.interop-project.identity.foundation/.well-known/did links to https://hub.identity.foundation
  3. https://verifier.interop-project.identity.foundation/.well-known/did links to https://hub.identity.foundation
  4. Subject uses hub sdk to request claims from https://hub.identity.foundation / stores / renders claims in app wallet
  5. Verifier does not use hub, but can verify claims presented by a subject who does use the hub, but who may also have a wallet app?
OR13 commented 5 years ago

I have opened this issue here:

https://github.com/decentralized-identity/hub-node-core/issues/26

kdenhartog commented 5 years ago

The example code here seems to indicate that read and write for hubs would work:

https://github.com/decentralized-identity/hub-sdk-js/blob/master/src/example.ts

If we were to take the hub approach is this how it would work?:

1. https://hub.identity.foundation is an Identity Hub for Interop Project DIDs.

2. https://issuer.interop-project.identity.foundation/.well-known/did links to https://hub.identity.foundation

3. https://verifier.interop-project.identity.foundation/.well-known/did links to https://hub.identity.foundation

4. Subject uses hub sdk to request claims from https://hub.identity.foundation / stores / renders claims in app wallet

5. Verifier does not use hub, but can verify claims presented by a subject who does use the hub, but who may also have a wallet app?

What's the linking used for in step 2 and 3?

OR13 commented 5 years ago

@kdenhartog this ticket was written before the difference between .well-known/did and .well-known/did-configuration had been flushed out.

Short answer is this does not make sense anymore if the issuer did is BTCR, since .well-known/did is reserved for did:web.

Long answer is that both the issuer and verifier are web servers which have DIDs of various methods linked, and this .well-known URI stuff is to expose the DIDs that are associated with a domain.

Since Hubs / Agents tend to be linked in serviceEndpoints, a domain now has the following mapping to hubs and agents:

example.com -> many dids -> many hubs and agents

If we plan to use a hub or an agent to transfer credentials, we need to know how to discover it. Thats what these .well-known bits are about.

OR13 commented 5 years ago

I'm going to close this for now, I think it is best tracked in the https://github.com/decentralized-identity/interop-project/issues/15

and https://github.com/decentralized-identity/interop-project/issues/4