decentralized-identity / .well-known Goto Github PK

The sample provided on the foundation website, is there any sample code or library that can be used to derive this "presentation" from the VC JWT that is included?

https://identity.foundation/.well-known/did-configuration.json

Do I have to manually map this in my own code, or does there exists something I could use?

I'm basically doing a software where when you set it up, you supply your DID and private key, and it will generate a signed "did-configuration.json" that will be provided by others who add your public server to their list of "vaults".

When users add a new server based on their domain name, the did-configuration.json will be verified, the software will do an DID resolving and get metadata for the server, like "name" and "description".

So in essence, convert an DID JWT VC to a type of DomainLinkageCredential to be included in the did-configuration.json.

I think that this repo can be used to test did:web, it would be awesome to get an example commited.

@pelle @awoie Can one of you link me to a did:web example, I will add it here, and back link to whatever you wish.

The entry array supports multiple DIDs. It is unclear when the verification process stops. A few questions that I have:

• Does the verification stop when any of the entries was failed to verify? That might be an issue in case virtual hostnames are supported.

• Does the verification stop when the first entry was successfully verified?

• Can the verifier choose which entry to pick first, i.e., which DID (method) to resolve, or is the order mandated?

see decentralized-identity/credential-manifest#19 (comment)

Re: https://identity.foundation/.well-known/resources/did-configuration/#domain-linkage-credential

Currently, the expirationDate member is a MUST within the Domain Linkage Credential which does not make sense for the entities who do not want to manage the well known document's lifecycle. Companies may want to add the document and just keep it there without having to worry about monitor the status of the document. If they miss to update the document then their DID-to-domain link breaks.

Making it optional makes sense as it allows for entities who do want it can then add it.

Its possible to use the .well-known/did-configuration to expose DIDs for the domain, that are "Company" DIDs, but its also possible for it to be "Customer" DIDs, or user DIDs...

The question here is about providing guidance on what kinds of DIDs should be associated with a domain.

It seems like we should take an authoritative stance, that this uri is not to be used for customer or user account/ user agent / wallet DIDs.

For an analogy, if we're talking about twitter:

https://twitter.example.com/.well-known/did-configuration

Would hold DIDs for the company twitter, but NOT twitter users.

This spec supports JSON-LD as well as JWT as format for the domain linkage credential resource. However, there are a few inconsistencies:

• The filename is always .json, which seems wrong for JWT, since the media type would be application/jwt and not application/json and most web servers would by default send the incorrect media type in the case of JWTs.
• Section 3 of the spec starts with "Given an origin, https://example.com, fetch the DID Configuration resource" and "Provided the call returns a successful response, ... parse the body as JSON" and "The DID Configuration resource MUST be a valid JSON object". This wouldn't work for JWT.

Suggesting pointing definition of Origin to IETF's The Web Origin standard https://tools.ietf.org/html/rfc6454#section-3.5.
This would not only make this well-known specification more stable, but also clarify that the specification applies to subdomains, which could be made more explicit in the spec.

Similar to how did web supports path based routing, it should be possible to say that a URL not an origin... is linked to a DID...

this would allow websites like github pages and any non DNS admins to use the spec.

We have a lot of duplicate markdown / respec like stuff.

We need to move everything that is "spec like" from:

https://github.com/decentralized-identity/.well-known/blob/master/resources/did-configuration/demo/README.md

into:

https://github.com/decentralized-identity/.well-known/blob/master/resources/did-configuration/index.html

The demo README should just point to the spec and describe development setup and tips.

In the abstract of the current spec, the following statement is made

The DID Configuration resource provides proof of a bi-directional relationship between the controller of an Internet domain and a DID via cryptographically verifiable signatures that are linked to a DID's key material

Can we clarify further what is meant by this? This implies you can start with a did and discover associated domains from it? That may just be my interpretation but to be clear, the current design does not allow this?

The example 2 contains one JSON-LD and one JWT example domain linkage credential. The JWT form uses credentialSubject.domain instead of credentialSubject.origin and may need to be updated.

@tplooker I would like to pull the "LinkedIdentifier" credential out of this spec, and into its own one, so it can be made more generic, and used outside of HTTP / well known endpoints.

Can you commit what you have somewhere so we can adopt support for it in this spec?

Prefer you open a CCG work item for it.

I just read the spec: https://identity.foundation/specs/did-configuration/

And it was unclear to me what the value of domain is in the claim. Or where the JWT is issued from?

Will it be the users of that did entry who signs of a JWT or something else?
The domain is there to match the domain the well-known is under?
Because this well-known document will be built up by the domain owner so he will only put in trustable information.

signed with the specified DID's keys

here and elsewhere there is an implication but multiple keys are signing the assertions in the configuration file entries. But a single assertion can only be signed by a single key. Is the expectation of that multiple assertions should be made, one per signing key? (To prove possession of all signing keys?) Or is the idea that the did owner can pick any signing key and make an assertion with just that one? I assume it is the latter, in which case we should update the language to use singular nouns and perhaps provide guidance how to identify signing keys within the did document.

Add a CNAME to DNS provider for identity.foundation.

well-known.identity.foundation -> decentralized-identity.github.io

Update ./docs/CNAME to match.

Rebuild and publish website to fix DNS.

Add language to add order-based processing and importance to the service endpoint array.

Can use https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js/tree/master/packages/es256k-jws-ts

All JWTs should be verifiable, and all properties should be defined.

I assume that the idea is to use the authentication section and in particular any of the verification methods included in it to verify the JWT? It is not explicitly stated which part to use. We should stick with the DID spec terminology.

The examples in the spec use did:key everywhere, but did:key only supports verificationMethod/keys and not services.

So the examples in the spec cannot satisfy the actual requirements from the spec as you cannot get the service with the origin in the DID.

Probably makes sense to use another DID method for the examples as to not confuse people.

As we look at how to make Credential Manifests discoverable, we have an opportunity to reuse the DID Configuration resource as the place to do that, as well as the things related to it. This might include a list of CMs (or references to them), details about issuance protocols (OIDC endpoints, DIDComms connection details, etc.). I think reusing this for more config stuff makes sense, given it is appropriately named/situated.

Per the RFC, data within /.well-known/ is not meant to be a new general namespace, but rather used for service discovery. Hosting non-metadata information such as the specification within /.well-known/ is outside the spirit of the RFC - which is a bit odd for a specification trying to define usage of well-known for a particular purpose.

Generally, if you aren't willing to publish an RFC about a resource under /.well-known/ and have it within the IANA registry, it does not belong under the /.well-known/ path.

what is the purpose ?

what is DID.configuration.json?

currently it uses the word "claims"

We're trying to publish a did-configuration.json file that uses a long-form DID -- see https://c19.cards/.well-known/did-configuration.json. The body is already larger than 8KB even with only a single entry in the array.

Is there a compelling reason to impose such a stringent limitation? (If so, we can probably drop parameters from the long-form DID in this case, but I'm anticipating that other use cases will require binding to multiple DIDs, which makes the limit even tougher.)

Its worth noting that JSON-LD has some opinions about well-known URIs... apparently they don't like them, and prefer to use HTTP headers...

https://web-payments.org/specs/source/secure-messaging/#the-key-registration-process

https://json-ld.org/spec/latest/json-ld-api-best-practices/#use-json-ld

Personally, I'm a bigger fan of well-known URIs than varying responses based on headers, especially since you typically need to configure a web server to support custom headers.

A link to assertionMethod in Section 5 is 404.
I think it should be https://www.w3.org/TR/did-core/#assertionmethod ?

This Well Known DID Configuration implementation addresses a particular need that we at Factom Inc are working to solve in a customer implementation. We appreciate all those that have put their time into publishing this specification.

Our implementation, and I can imagine that of others, will be tightly related to our Verifiable Credentials solution. In our VC solution, the credentials and presentations leverage cryptographic linked data proofs. As such, adoption of the Well Known DID Configuration hinges on our ability to leverage this infrastructure.

Specifically, we are requesting the 3 Cryptographic Linked Data proofs outlined here be supported. This includes:

• Ed25519Signature2018
• RsaSignature2018
• EcdsaSecp256k1Signature2019

cc @OR13

It has been discussed before, but there is now actual movement on it... see: w3c/did-core#33

{
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld"
        ],
        "id": "https://example.com/credentials/0",
        "type": ["VerifiableCredential", "DomainLinkageAssertion"],
        "issuer": "did:key:z6Mktts3kfFWDrURs7fNpayz24LZeCGNvCaFMC6KkbeYpZvi",
        "issuanceDate": "2019-12-02T15:08:37.751Z",
        "credentialSubject": {
          "domainLinkageAssertion": {
            "domain": "identity.foundation"
          }
        },
        "proof": {
          "type": "Ed25519Signature2018",
          "created": "2020-01-31T21:02:49Z",
          "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..ByLGBlulPIH2N-WwQvdNejEQoAQb5kk11hDn_Palp8QcGssOo19Vc6TYSUkCAV7BpzHGclZNdQaY5D98krojAw",
          "proofPurpose": "assertionMethod",
          "verificationMethod": "did:key:z6Mktts3kfFWDrURs7fNpayz24LZeCGNvCaFMC6KkbeYpZvi#z6Mktts3kfFWDrURs7fNpayz24LZeCGNvCaFMC6KkbeYpZvi"
        }
      }

and

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld"
    ],
    "type": [
      "VerifiableCredential",
      "DomainLinkageAssertion"
    ],
    "credentialSubject": {
      "domainLinkageAssertion": {
        "domain": "identity.foundation"
      }
    }
  }

My understanding is that credentialSubject block might not need domainLinkageAssertion nesting, but that this is handy if you wanted to add other assertions to the same section...

We can easily make the structure of this credential whatever we like, I'd like to gather additional feedback on this issue.

• Update Spec
• Update Demos

Could you add support for multiple hostnames, or if the intention was to support that, to make that explicit.

This issue is related to a previous discussion in #18.

Say the following credential has been issued

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ], 
  "id": "1872", 
  "type": ["VerifiableCredential", "AlumniCredential"], 
  "issuer": "did:example:c276e12ec21ebfeb1f712ebc6f1", 
  "issuanceDate": "2010-01-01T19:73:24Z", 
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": {
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:example:c276e12ec21ebfeb1f712ebc6f1#key-1",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

For human readability purposes, credential processing software in some instances would benefit from being able to substitute the domain name if there is one associated to the issuers DID in a UI rendering for this credential. However, the current spec does not support DID to domain discovery.

To support this functionality we could use DID service endpoints in the following way.

Assume the domain of example.edu hosts a /.well-known/did-configuration resource establishing a link with did:example:c276e12ec21ebfeb1f712ebc6f1

If the DID document of did:example:c276e12ec21ebfeb1f712ebc6f1 looked like the following, the well-known resource could be discovered from the DID.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
  "authentication": [{
    "id": "did:example:c276e12ec21ebfeb1f712ebc6f1#key-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:c276e12ec21ebfeb1f712ebc6f1",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    "id":"did:example:c276e12ec21ebfeb1f712ebc6f1#domain-link",
    "type": "DomainLink",
    "serviceEndpoint": "https://example.edu/.well-known/did-configuration"
  }]
}

Thoughts @csuwildcat @peacekeeper @OR13?

I'm unconvinced whether this would need to be directly in this specification it could just be an optional discovery mechanism?

1.) The status in the spec still reads "DIF Working Group Approved Draft" but the SC approved it. The DIF Charter official title for this status is "Approved Deliverable". I'm happy to dive into the ReSpec and open the PR myself, if the chairs prefer.

2.) Likewise, there was some discussion on Slack about adding a "Known Implementations" section with links to live .wellknowns. For now, I added these to the readme.md here on github-- should they be moved into the spec, or should the spec link directly to the readme section? Again, happy to do myself if it's non-controversial, but consensus from chairs preferred :D

@csuwildcat @tplooker @OR13

Per the documentation here: https://github.com/decentralized-identity/.well-known/tree/master/resources/did-configuration

@csuwildcat indicated in DIF slack that he could not run the example / demo:

$ npm start
> [email protected] start C:\repos\well-known\resources\did-configuration
> react-scripts start
'react-scripts' is not recognized as an internal or external command,

Possibly a windows issue.

similar to w3c-ccg/did-method-web#73

Need to make sure we are available to respond to requests.

did.json example in readme:
https://identity.foundation/.well-known/did.json

I have added the general concept to the spec, at the entry level, but we need to decide on a few things:

1. Do we recognize multiple primary references?
2. If we do not allow multiple references (my preference) how do we disregard multiple references present? I would argue we honor the one that is found first in a standard JSON parse/iteration of the object.
3. Do we need to include a reference both in the unsigned entry object and the inner JTW, to ensure primary is a protected declaration?

An apparently older version of the well known DID spec is still available at https://identity.foundation/specs/did-configuration/, potentially causing confusion. Should it be removed?

Lets make the URL look nice.... either:

https://identity.foundation/.well-known/did-configuration/v1

or

https://w3id.org/did-configuration/v1

In this section it speaks of a trusted browser based API being invoked to validate the QR content prior to display for scanning via the identity wallet. Because the scanning is still an extra step, shouldn't the Identity Wallet instead being doing this validation on the content decoded from the QR-Code, otherwise forged QR-Codes could still be generated in browser that simply bypass the usage of the trusted browser API?

I don't think of myself as a newbie to DIDs (VCs, and SSI stuff), but nevertheless I find it difficult to grasp the ideas behind this (and some other) repo's. It would be helpful if the README could link to, or itself provide texts that help readers understand the gist of what's being done here without assuming them to already know what's there. It's ok to refer to similar texts (in other repo's) if they are prerequisite reading and provided they exist.

Can this be done?

In order to get the spec registered with IANA, we will need to add sections like this to the doc: https://openid.net/specs/openid-connect-discovery-1_0-29.html#IANA