Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-12-14 01:54:28 -05:00
Code Issues Packages Projects Releases Wiki Activity
148d3df255
decentralized-id.github.io/_posts/identosphere-dump/open-standards/decentralized-identifier.md
⧉ infominer 063d78881c organization
2022-12-04 02:46:02 -05:00

22 KiB
Raw Blame History

Decentralized Identifier

“I would summarize the overall impact of DIDs on cybersecurity as making digital signing and encryption much more widely available than today’s conventional X.509-based public key infrastructure (PKI),” Drummond Reed, director of trust services at Avast

DIDs are a critical part of a technical foundation for the products and activities of many of our members. Many of the implementations in the DID Working Group’s implementation report were developed by engineers and companies who collaborate openly at DIF on points of technical interoperability, and at ToIP on points of policy and governance.

  • Indicio’s support for the W3C DID Specification and its path to standardization

    The position of Indicio is that the DID Specification is of signal importance to creating a better digital world. We recognize that, as with any specification, improvements can and will be made in the future; but we back its recommendations and its approval.

  • ENS names are Decentralized Identifiers (DIDs) uPort
    • did:ens:mainnet:vitalik.eth

    This has two purposes:

    1. to wrap existing ENS names as DIDs to facilitate interoperability of emerging technologies in the Decentralized Identity and Ethereum community,
    2. to define a canonical way to augment ENS names with DID capabilities (e.g., encryption) as mentioned above.
  • Community Resources - DID Primer Credentials Community Group

    At a superficial level, a decentralized identifier (DID) is simply a new type of globally unique identifier. But at a deeper level, DIDs are the core component of an entirely new layer of decentralized digital identity and public key infrastructure (PKI) for the Internet. This decentralized public key infrastructure (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the SSL/TLS protocol for encrypted Web traffic (now the largest PKI in the world).

  • Cryptography Review of W3C VC Data Model and DID Standards and Implementation Recommendations SRI International
  • Adding DID ION to MATTR VII

    Different types of DIDs can be registered and anchored using unique rules specific to the set of infrastructure where they’re stored. Since DIDs provide provenance for keys which are controlled by DID owners, the rules and systems that govern each kind of DID method have a significant impact on the trust and maintenance model for these identifiers.

DID Core advances to recommendation

The DID core specification is approved to advance to W3C Recommendation.

In its next chartered period the Working Group should address and deliver proposed standard DID method(s) and demonstrate interoperable implementations.  The community and Member review of such proposed methods is the natural place to evaluate the questions raised by the objectors and other Member reviewers regarding decentralization, fitness for purpose, and sustainable resource utilization. -Ralph Swick, for Tim Berners-Lee

Announcing the Decentralized Identifiers (DID) v1.0 specification as an open web standard signals that it is technically sound, mature, and ready for widespread adoption. Having an established v1.0 specification allows work to continue with renewed energy and focus, not only at the many groups meeting at DIF, but across the digital identity community.

Part 2 of this 2-part series explains the did:pkh/CACAO variation for Verite data models and flows, which provides an entry path for wallets that may not support sufficient functionality for emerging decentralized identity patterns

tldr :: DID is just an URI :: VC is a cryptographically verifiable credential using DID :: SSI is a self-sovereign and privacy-preserving identity :: Non-human (Machines, Bots, Goods, anything) also able to have DID, VC, and SSIs

The Universal Resolver can now resolve 45 DID methods, and more are being added regularly. Visit https://dev.uniresolver.io/ to see the full list of supported methods, and visit this github page to contribute a driver for a DID method.

Good news to see Cardano jumping on the bandwagon, looks like they will join the fray and bring DID\VC to Atla Prism.

The recent DID core specification approval at the World Wide Web Consortium (W3C) provided clearer and stronger foundations for identity platforms building decentralized identifiers.

  • DID test suite GitHub

    DID test suite is not for runtime, but the Universal Resolver could do a few simple checks on a driver's responses. But there's also a philosophical question: Should the Universal Resolver be "allowed" to check and potentially transform driver responses, or should it just "pass through" everything that comes from a driver?

  • did:orb slides Troy Ronda (SecureKey)

    • Decouple witness ledgers from the critical path.
    • Allow for Trust but Verify model.
    • Leverage the Certificate Transparency model
    • Witnesses observe VDR objects and promise to include in their ledgers.
    • Provide a signed timestamp and a maximum merge delay.
    • Enable monitoring to ensure witnesses follow their promises.
    • Use trusted Witness (and origin) timings to resolve late publishing.
    • Use origin to enable observers to know if they have the latest operations.

  • re: Defining load balanced, failover clusters for DID Document serviceEndpoints? (Monday, 10 January)

#didlang 0.3 includes support for round-robin, load-balanced DID Agent serviceEndpoint clusters. Here's a demo

This is the final step of the W3C global standardization process.

If you are a W3C Member, you can now vote to approve it as a global standard here:

  1.  Governments “lobbying” for single DID method and Non-Interoperability

  •   “tantek: concerned to hear that there are governments looking to adopt, with only single implementation methods and non interop, sounds like lobbying may have occurred, … advocating for single-implementation solutions that are centralized wolves in decentralized clothing”

  •   “ +1 to tantek's concern that governments are responding to lobbying attempts on non-interoperable methods”

  • Mozilla Formally Objects to DID Core  Drummond Reed (Thursday, 1 September)

Now, here's the REAL irony. Mozilla and others are pointing to the URI spec and existing URI schemes as the precedent without recognizing that in in section 9.11 of the DID spec, we specifically compare the DID spec to the URN spec, RFC 8141. In fact we deliberately patterned the ABNF for DIDs  after the ABNF for URNs—and patterned DID method names after URN namespaces. And we set up a registry for the exactly the same way RFC 8141 establishes a registry of URN namespaces.

Now: guess how many URN namespaces have been registered with IANA?

I don't see anyone complaining about interoperability of URN namespaces. Amd RFC 8141 was published over four years ago.

The motivation for verification relationships in the DID spec stems from the general security recommendation of "use separate keys for separate purposes".

You can see this at work in other specifications, such as JWKS (JSON Wek Key Set), specifically in the 'use' (Public Key Use) parameters, from https://datatracker.ietf.org/doc/html/rfc7517#section-4.2

great to see that press release at https://www.w3.org/2022/07/pressrelease-did-rec.html.en

There's a testimonial from UNECE near the bottom.  I thought the community might be interested in the white paper from UNECE on VCs and DIDs for cross border trade - https://unece.org/trade/uncefact/guidance-material

This message is to inform the DID WG and CCG that the W3C intends to write a press release.

To that end, we are seeking testimonials about Decentralized Identifiers.

For an example of the sort of thing we're looking for, please see: https://www.w3.org/2019/03/pressrelease-webauthn-rec.html

The testimonials may be submitted as a reply to this email.

DID Methods

The publication of this DID Method specification realizes, in large part, a 4-year quest (or should I say personal mission) to create a platform to Tokenize Every Little Thing (ELT).

On 8/26/21 12:37 PM, Heather Vescent wrote:

  1. What are the pros of including did methods as work items in the CCG?

Community vetting and approval of particular DID Methods.

Basically, broader and deeper review of DID Methods that we expect to be of

great use to the world. I expect there will be DID Methods that the community

wants to eventually propose as DID Methods for standardization (did:key and

did:web feel like two ones where we could get consensus on doing so).

can't we pick just a small number of un-controversial methods to standardise?  even if it's just did:key and did:web to start with.

The broader generalisation of this question is : "for trust anchors like governments that issue VCs to their constituents, what rules should govern which did:methods they should accept as the subject identifier for the VCs they issue?"  Are those rules context specific?

I'm not sure of the answer - but it's why did:ion was on my list - as an allowed subject of a government issued vc - and as the issuer of trade documents.  should I take it off my list pending a bit more maturity (eg that azure service goes out of beta into full production)?  or is it safe enough for this use case?  if so what others would also be "safe enough"?

https://www.notion.soimages/image2.png

DID:TAGre: Using Email as an Identifier  Bob Wyman (Friday, 12 November)

My did:tag proposal is, I believe, the only proposed DID Method that addresses the use of email addresses and email as a resolution method

There are quite a number of issues with using email addresses as identifiers, or parts of identifiers, and I'm hoping that discussion and development of the did:tag method will illuminate those issues and potentially find solutions for them.

DID:WEB

We have had the same issue... per the did core spec, there are really 2 main key types, in our crypto libraries for the key pair classes themselves, we do our best to support both and handle translation for you:

We then generate a DID Web DID Document from the public keys for the 3 children, and encode the ca chain from them back to the root using x5c.

We then issue a JWT from the private key for 1 of them.

We then verify the JWT signature using the public key.

We then check the x5c using open seel to confirm the certificate chain.

My questions are:

  1. Is it possible to use JOSE to automate this further?

  2. Is there a better way of accomplishing this?

  3. Should the CA chain be pushed into the JWT?

DID:JWK

DID:KEY

I published a did:key creator at

This has been tested to create did:keys from the P-256,P-384, and P-521 curves specified in https://github.com/w3c-ccg/did-method-key and https://w3c-ccg.github.io/did-method-key/ .

The DID Document generation algorithm for did:key is being refined to the

point that we can finish off a first pass of a did:key test suite.

Our latest implementation report for DID Core is available here:

Here are the remaining items that the WG needs to discuss on the upcoming call:

#1: Are the hl, relativeRef, and service implementations independent enough?

  • [...]

#2: Are we letting the JSON serialization keep unimplemented features?

  • [...]

#3: What are we going to do with deactivated, nextUpdate, and nextVersionId?