Since the key used to issue the credential needs to be in the DID document for the issuer, the key needs to be a supported key format for the issuer DID Method.

This issue is blocked by #2

See comments below, the spec for this is being tracked:

https://github.com/decentralized-identity/well-known/tree/master/did-configuration

This ticket contains a lot of ideation, please refer to the spec ^.

We propose that the .well-known/did standard be used to exposing the DIDs used by this web server.

I don't see the spec for this anywhere... so we need that, or we will have to use a hack like:

HTTP GET http://example.com/.well-known/did

{
  "dids": ["did:ethr:fff...."],
  "registered_did_jwts": [...]
}

Where a registered_did_jwt is a JWS from a did listed in "dids" of a payload:

{
 "iss": "did:ethr:fff...",
 "sub": "did:ethr:fff...",
  "dif_authorized_credential_issuer_vc_v0": "http://example.com"
}

If this signature is valid, then the DID is a credential issuer for http://example.com

I'm making this all up, we should really have a standard for .well-known/did

With AuthN Adopted, it is now time to discucss credential exchange / delivery.

There are Agents and Hubs, as well as HTTP, Identity Wallets, all will have opinion about how they would like to receive credentials.

Lets continue the discussion regarding DIDComm and Agent / Hub Integration.

Please comment a completed end to end example of how you think this can work, with links to supporting documentation.

Anything supported by https://uniresolver.io/ seems like a good candidate.

Keep in mind that the issuer just needs to have a DID with a key that is available to the credential issuing server. Its a one time setup to get the key into the DID Document, so cost for ledger methods should be safe to ignore.

Add your method or vote for one.

issue

Let use consider the case of using OIDC SIOP QR Codes, separate from potential DIDComm QR Codes.

OIDC SIOP does not have a concrete implementation yet: #14

In order to complete one, we need to commit to the QR Codes and share enough information about the implementation to support Identity Wallet providers.

The specific handling of the QR Codes is according to the spec

This ticket is considered done where there is an OIDC SIOP demo checked into this repo.

https://github.com/decentralized-identity/papers/blob/master/did-authn/siop/did-authn-siop-profile.md

We might consider the deliverables to be a set of libraries implementing OIDC SIOP for iOS and Android, and Node.js.

Open to other suggestions.

I have this issue: #25 which is more around the DID and how that can be portable and how to do it.

Then I have another issue of interoperability/portability. That is what happens to the VCs after you are deemed necessary to move to another did, because did:x became unsafe, or you want some other mechanisms offered at that DID?

First case:
All your VCs, you are still in possession of, but the subject of that VC is the did you have decided to no longer use. What are the right way of proving control over these VCs?

You can wrap it all in a presentation with your new DID method, and sign it. Which proves you are in possession. But it does not prove the rightful ownership of those VCs? Is this where, before you move a DID, you do a self issuing VC, renouncing all your VCs to that new DID? So you can build a chain of trust? How do you even model this?

Second case:
You lose control of the DID because of the unsafe ledger was taken over. But not the VCs. Is this a completely different case where recovery mechanisms and other stuff come into play? Or is this also a play where you simply have a way of saying that this new DID control these VCs? I see the implications in the matter that if I'm to prove I had control over an identifier, I would need some data points for that person to trust that this new DID is the same person.

I believe the first case is solvable but would like to hear what you guys think about best practices around that.
Second case I'm more in the shadows about.

IMO this one is far more important since there will likely be many subjects all wanting credentials from a single issuer.

This means that cost should be considered, as well as ease of creating and managing your DID.

In order for the issuer to authenticate the subject before issuing a credential, the subject will be required to provide a signature, so again usability will be key.

I guess technically we don't need to limit the credential subject to a specific DID Method, assuming we rely on the https://uniresolver.io/.

It is the case that a resolver is required to authenticate a DID, so supporting the DID Methods the uniresolver supports seems like a good idea.

Add your favorite DID Method or vote for one.

The issuer website needs to challenge a DID to sign a QR code (more details in future tickets).

In order for the issuer to authenticate the subject, the issuer and subject need to agree on a ciphersuite.

jose based jwt is the most interoperable, I strongly suggest we use it.

We even have https://github.com/decentralized-identity/did-auth-jose

I'd like to see RSA here, since its likely to be equally unpopular with all members, and its also well supported by languages.

I think OIDC SIOP is out of scope for this.

There is some summary here:

https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md

I think we need to agree to a simple JWT Challenge Response flow for the purposes of authentication.

This package is also linked on the credential format ticket:

https://www.npmjs.com/package/@panva/jose

To my knowledge it supports all the key types we need, so if we adopt JWT / JWE with this package I think we can close this ticket.

I'm interested in this project: https://reticulum.network/index.html

Specifically whether the Identities: markqvist/Reticulum#155 (comment)

Created by the https://github.com/markqvist/sideband#sideband- application

Could be made DID-compatible. What would need to be changed to make it DID-compatible?

I still think we really need to demonstrate DID Auth, but do we really need DID Auth if we are using verifiable presentations?

Sure I can get a verifiable credential for a given did, but won't the presentation be impossible to create unless I control signing keys linked to the verifiable credential subject/holder?

I think the crux of this issue is that while verifying a JWS or JSON-LD Signature is a clearly defined process. Verifying a VC or VP is defined by:

https://www.w3.org/TR/vc-data-model/#dfn-verify

What does it mean for me to create a VP of a VC membership credential issued to @christianlundkvist to the DIF verification service? Should that service only accept VPs that are signed by the subject of the VC they wrap?

There are 2 signatures here... and they can come from the same or different DIDs...

We need to define what verification means for VPs of the format:

https://jwt.io/#debugger-io?token=eyJhbGciOiJFUzI1NksiLCJ0eXAiOiJKV1QiLCJraWQiOiJkaWQ6ZWxlbTplVVJTRkVFdjZKN3MzVEotamhUX1pTNHVHUnlDRGJ3YzM0N0VXbHFwTmd3I2tleS1IZ0duSFVOVG5JUTdtSWZTbEc0VmhIc0RHTnZwb09DT3JTOWdkZUhFNFVzIn0.eyJqdGkiOiJ1cm46dXVpZDoxZGQ2NGU1OC03OTk0LTRiZjEtOTc0YS03NWNmOTQwMzMzMTEiLCJpc3MiOiJkaWQ6ZWxlbTplVVJTRkVFdjZKN3MzVEotamhUX1pTNHVHUnlDRGJ3YzM0N0VXbHFwTmd3IiwiYXVkIjoiZGlkOmV4YW1wbGU6MTIzIiwiaWF0IjoxNTY3NzkyMzQxLCJuYmYiOjE1Njc3OTIzNDEsImV4cCI6MTkyNzc4ODc0MSwidnAiOnsiQGNvbnRleHQiOlsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy9leGFtcGxlcy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVQcmVzZW50YXRpb24iLCJDcmVkZW50aWFsTWFuYWdlclByZXNlbnRhdGlvbiJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6WyJleUpoYkdjaU9pSkZVekkxTmtzaUxDSjBlWEFpT2lKS1YxUWlMQ0pyYVdRaU9pSmthV1E2Wld4bGJUcGxWVkpUUmtWRmRqWktOM016VkVvdGFtaFVYMXBUTkhWSFVubERSR0ozWXpNME4wVlhiSEZ3VG1kM0kydGxlUzFJWjBkdVNGVk9WRzVKVVRkdFNXWlRiRWMwVm1oSWMwUkhUblp3YjA5RFQzSlRPV2RrWlVoRk5GVnpJbjAuZXlKemRXSWlPaUprYVdRNlpYaGhiWEJzWlRveE1qTWlMQ0pxZEdraU9pSjFjbTQ2ZFhWcFpEbzNPRFkxWkRBMFlTMDFabVZsTFRRMFpHUXRZV0U1TlMwME9UZ3dZemd6Wm1JME1qWWlMQ0pwYzNNaU9pSmthV1E2Wld4bGJUcGxWVkpUUmtWRmRqWktOM016VkVvdGFtaFVYMXBUTkhWSFVubERSR0ozWXpNME4wVlhiSEZ3VG1kM0lpd2lhV0YwSWpveE5UWTNOemt5TXpNMExDSnVZbVlpT2pFMU5qYzNPVEl6TXpRc0ltVjRjQ0k2TVRreU56YzRPRGN6TkN3aWRtTWlPbnNpUUdOdmJuUmxlSFFpT2xzaWFIUjBjSE02THk5M2QzY3Vkek11YjNKbkx6SXdNVGd2WTNKbFpHVnVkR2xoYkhNdmRqRWlMQ0pvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2TWpBeE9DOWpjbVZrWlc1MGFXRnNjeTlsZUdGdGNHeGxjeTkyTVNKZExDSjBlWEJsSWpwYklsWmxjbWxtYVdGaWJHVkRjbVZrWlc1MGFXRnNJaXdpVlc1cGRtVnljMmwwZVVSbFozSmxaVU55WldSbGJuUnBZV3dpWFN3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2laR1ZuY21WbElqcDdJblI1Y0dVaU9pSkNZV05vWld4dmNrUmxaM0psWlNJc0luVnVhWFpsY25OcGRIa2lPaUpOU1ZRaWZYMTlmUS4tV295SGpBNkFGLUZscUpPTXZzMHhoZTBlZ0thMFRjTWllZDJsbEkzVUE1TGhTaWk5RHRiSEdwbkI5ZWNXa3dmYjJUdmdYZVY3dmpMVTl0Mk9OOExKQSJdfX0.asTnrgdyWYOuLxAMYNtKBpEFWjm2Ih0yI7nfxCrM-Sx56-9Xgcge2w-QNzECcijbWbwnPAiycM78W6ODi0lhXg

In particular how are the VC and VP issuer related or not.

It would be helpful to have some simple scripts for creating and updating BTCR DIDs.

For updates, we would want to support key registration for Ed25519, Secp256k1 and RSA.

I believe this is an interesting case for interopability. I did not want to write things twice, so I will just reference the main issue here. Then we can have a discussion on a more general level in this issue.

jolocom/smartwallet-app#1502

Questions
Is this a case that would happen in the future for services?
As a service provider I should never have to choose the identity service?
Is a https://iancoleman.io/bip39/ seed enough to cater to exportation of identity services?
Do you have any other thoughts around this?

Interop_Survey_export.pdf

In order to provide the proper level of modularity, and support easy contribution, I'm recommending the following project structure.

0. JavaScript (not TS or Coffee)
1. Lerna Mono Repo https://github.com/lerna/lerna
2. Travis CI
3. CodeCov
4. Github Pages for Documentation
5. Docker Support For Development Environment

More controversial:

• React/SPA for Verifier + Issuer Web Sites
• Storybook for UI Components
• Express JS for Web Server

There was substantial discussion regarding support for vc-authn-oidc here:
#9

https://github.com/bcgov/vc-authn-oidc/tree/master/docs

@swcurran @dhh1128 @awoie

I'd like to continue the integration conversation on a clean ticket that is just about adding support for vc-authn-oidc

I recognize that SIOP by itself does not address the same use case, as @awoie noted on #9.

I'm wondering whether we can sketch out what using vc-authn-oidc would look like for interop project end to end on this thread.

https://github.com/rabobank-blockchain/vp-toolkit#flow

iGrant.io_DW_V13.1_DIF_Demo.pdf

I recommend ES256K (Unencrypted) JWT for Credential and Presentation, see the format proposed by @awoie below.

Please note that the DID AuthN review period will end by August 11th. The goal is to decide whether to use the SIOP spec in the course of the interop project.

The current proposal/ paper can be found here: https://github.com/decentralized-identity/papers/blob/master/did-authn/siop/did-authn-siop-profile.md

This will allow us to bring the decision to the next interop call.

If no substantial objections will be brought up and we can reach consensus, we will use the DID AuthN SIOP profile.

Please add Identity Wallet Mobile apps that would like to be supported, and comment on the idea of implementing a QR Code flow.

Excluding Agents and Hubs, can we show credential signing and verifying using the unviersal resolver and https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js/tree/master/packages/es256k-jws-ts

We already have a very similar demo here:

https://github.com/decentralized-identity/well-known/tree/master/did-configuration

The demo should include:

1. DID Creation of Issuer BTCR DID (partially complete and checked in)
2. DID Creation of a Subject (your pick!)
3. Credential creation and signing by issuer.
4. Credential verification using the universal resolver

All private keys used should be statically configured, and no existing keys should be used (for security reasons).

A possible option for getting credentials to a wallet:

https://github.com/digitalbazaar/credential-handler-polyfill

If we could demonstrate how this works with at least 1 mobile wallet, it might help encourage wallet implementers to support this standard.

Chadwick_DIFpresn_9jun21.pdf

In order for a Hub or Agent implementation to be supported, a document must be contributed to this repo describing how to leverage the Hub / Agent with at least 2 different DID Methods.

All code necessary to complete the linking should be included, such as protocol messages, public web service endpoints, authentication details, etc.

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:[email protected]

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.