Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-10-01 05:05:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

standards sort

Browse Source
This commit is contained in:
⧉ infominer 2022-12-16 16:07:05 -05:00
parent 40b64f21d4
commit 73f0b55df7
8 changed files with 112 additions and 119 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
identosphere-dump/open-standards/README.md
View File

@ -1,5 +1,12 @@
# Web Standards
- aggregate well-known-did-1-of-a 1 of a (intermediate)
- aggregate did-spec-registries-1-of-a Signature Implementations 1 of many (intermediate)
- aggregate did-spec-registries-1-of-b did-method 1 of many (intermediate)
- web-idl [Web Interface Definition Language](https://heycam.github.io/webidl) (non-core)
- MATTR bbs-signatures-spec [BBS+ Signature Scheme](https://mattrglobal.github.io/bbs-signatures-spec) (core)
- rdf-dataset-normalization [RDF Dataset Normalization](https://json-ld.github.io/normalization/spec) (non-core)
## W3C
Decentralized Identifier ✓
@ -22,6 +29,34 @@ Verifiable Credential
JSON-LD
- [Complementary] JSON-LD ✓ (W3C)
- [W3C] did-core [Decentralized Identifiers (DIDs) V1.0](https://www.w3.org/TR/did-core/) (core)
- [W3C] did-spec-registries [DID Specification Registries](https://w3c.github.io/did-spec-registries) (core)
- [W3C] security-vocab [The Security Vocabulary](https://w3c-ccg.github.io/security-vocab) (core)
- [W3C] Ed25519-signature-2018 [Ed25519 Signature 2018](https://w3c-ccg.github.io/lds-ed25519-2018) (core)
- [W3C] EcdsaSecp256k1-signature-2019 [Ecdsa Secp256k1 Signature 2019](https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019) (core)
- [W3C] RSA-signaturesuite-2018 [RSA Signature Suite 2018](https://w3c-ccg.github.io/lds-rsa2018) (core)
- [W3C] did-resolution [Decentralized Identifier Resolution](https://w3c-ccg.github.io/did-resolution) (core)
- [W3C] did-method-key [The did:key Method](https://w3c-ccg.github.io/did-method-key) (non-core)
- [W3C]|DIF did-method-peer [Peer DID Method Specification](https://identity.foundation/peer-did-method-spec) (non-core)
- [W3C]|Sovrin did-method-sovrin [Sovrin DID Method Specification](https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html) (non-core)
- [W3C] did-method-web [did:web Method Specification](https://w3c-ccg.github.io/did-method-web) (non-core)
- [W3C] JSON-LD [A JSON-based Serialization for Linked Data](https://www.w3.org/TR/json-ld11) (non-core)
- [W3C] XSD-Part2-Datatypes [XML XSD<53> Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/) (non-core)
- [W3C] vc-data-model [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model) (core)
- [W3C] vc-use-cases [Verifiable Credentials Use Cases](https://www.w3.org/TR/vc-use-cases) (core)
- [W3C] vc-imp-guide [Verifiable Credentials Implementation Guidelines 1.0](https://w3c.github.io/vc-imp-guide) (core)
- [W3C] vc-extension-registry [Verifiable Credentials Extension Registry](https://w3c-ccg.github.io/vc-extension-registry) (core)
- [W3C] vc-status-rl-2020 [Revocation List 2020](https://w3c-ccg.github.io/vc-status-rl-2020/) (core)
- [W3C] vc-json-schemas [Verifiable CRedentials JSON Schema Spec](https://w3c-ccg.github.io/vc-json-schemas) (core)
- [W3C] vp-request-spec [Verifiable Presentation Request Specification](https://w3c-ccg.github.io/vp-request-spec) (core)
- [W3C] CHAPI [Credential Handler API](https://w3c-ccg.github.io/credential-handler-api) (core)
- [W3C] credential-management [Credential Management Level 1](https://www.w3.org/TR/credential-management-1) (non-core)
- [W3C] secure-contexts [Secure Contexts](https://www.w3.org/TR/secure-contexts) (non-core)
- [W3C] service-workers-1 [Service Workers 1](https://www.w3.org/TR/service-workers-1) (non-core)
- [W3C] ldp-bbs2020 [BBS+ Signatures 2020](https://w3c-ccg.github.io/ldp-bbs2020) (core)
- [W3C] ld-proofs [Linked Data Proofs](https://w3c-ccg.github.io/ld-proofs) (core)
- [W3C] ld-cryptosuite-registry [Linked Data Cryptographic Suite Registry](https://w3c-ccg.github.io/ld-cryptosuite-registry) (core)
### Data Privacy Vocab
* [https://kantarainitiative.org/confluence/collector/pages.action?key=WA&src=sidebar-pages](https://kantarainitiative.org/confluence/collector/pages.action?key%3DWA%26src%3Dsidebar-pages)
@ -48,6 +83,24 @@ Please provide your comments by 15-OCT-2022 via [GitHub](https://github.com/w3c/
- [Authorization] OAuth ✓ (IETF)
- [ID-Non-SSI] OAuth (IETF)
- [ID-Non-SSI] SCIM (IETF)
- [DIF] well-known-did [Well Known DID Configuration](https://identity.foundation/.well-known/resources/did-configuration) (core)
- [DIF] presentation-exchange [Presentation Exchange](https://identity.foundation/presentation-exchange) (core)
- [DIF] didcomm-messaging [DidComm Messaging](https://identity.foundation/didcomm-messaging/spec) (core)
- [DIF] did-comm-messaging-guide [DIDComm Messaging Implementer's Guide](https://identity.foundation/didcomm-messaging/guide) (core)
- [DIF] EcdsaSecp256k1-recoverysignature-2020 [EcdsaSecp256k1RecoverySignature2020](https://identity.foundation/EcdsaSecp256k1RecoverySignature2020) (core)
- [IETF] multibase [Multibase Data Format](https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03) (non-core)
- [IETF] JWK [JSON Web Key](https://tools.ietf.org/html/rfc7517) (non-core)
- [IETF] Timestamps [Date and Time on the Internet: Timestamps](https://tools.ietf.org/html/rfc3339) (non-core)
- [IETF] JWT [JSON Web Token](https://tools.ietf.org/html/rfc7519) (non-core)
- [IETF] JWS [JSON Web Signtaures](https://tools.ietf.org/html/rfc7515) (non-core)
- [IETF] hashlinks [Cryptograohic Hyperlinks](https://tools.ietf.org/html/draft-sporny-hashlink-06) (non-core)
- [IETF] Token Binding [Token Binding Protocol](https://tools.ietf.org/html/rfc8471) (non-core)
- [IETF] ZLIB [ZLIB Compressed Data Format Spec v3.3](https://tools.ietf.org/html/rfc1950) (non-core)
- [IETF] Base 64 [Base16, Base32, Base 64 Data Encodings](https://tools.ietf.org/html/rfc4648) (non-core)
- [IETF] JWM [JSON Web Message](https://tools.ietf.org/id/draft-looker-jwm-01.html) (non-core)
- [IETF] JWA [JSON Web Algorithms](https://tools.ietf.org/html/rfc7518) (non-core)
- [IETF] JWS-unencoded-payload [JSON Web Signature (JWS) Unencoded Payload Option](https://tools.ietf.org/html/rfc7797) (non-core)
- [IETF] jwk-thumbprint [JSON Web Key (JWK) Thumbprint](https://tools.ietf.org/html/rfc7638) (non-core)
### OASIS

4
identosphere-dump/open-standards/authorization/gnap.md
View File

@ -25,3 +25,7 @@ Clearly GNAP can replace OAuth, but I think you both have now confirmed that GNA
> The decision was made to create a new group apart from OAuth, and Dick clarifies that the GNAP working group does not feel constrained by existing technology; GNAP does not need to be backward-compatible, but Dick still hopes that the transition to GNAP will be smooth for those who use it.
* [Filling in the GNAP](https://medium.com/@justinsecurity/filling-in-the-gnap-a032453eaf8c)
> Justin Richer identity protocol writer and implementer extraordinaire has a very excellent post explaining the new GNAP and all the things that lead to it, including OAuth, OpenID, TxAuth, OAuth3, and OAuth.XYZ. This protocol is a big deal and will be important. It’s just beginning the journey through IETF (Internet Engineering Task Force) the main standards body of the internet.
* [Self-Sovereign Communities of Self-Sovereign Agents](https://iiw.idcommons.net/10H/_Self-Sovereign_Communities_of_Self-Sovereign_Agents) by Adrian Gropper
> Minimal Demo: [https://adriang.xyz/](https://adriang.xyz/) Use Card Number 4242 4242 4242 4242  04/22 123 (don’t use a real email address because it will be stored in Stripe.)
* [Demo sequence diagram](https://github.com/HIEofOne/Trustee-Community/wiki)
> The first phase of the foundation demos GNAP control over a trivial health record consisting of just a biometric health card.

33
identosphere-dump/open-standards/not-ssi/README.md
View File

@ -72,39 +72,6 @@ This specification defines event types and their contents based on the [SSE Fram
* [Security Event Tokens, Subject Identifiers, and SSE/CAEP/RISC Java implementation](https://iiw.idcommons.net/13A/_Security_Event_Tokens,_Subject_Identifiers,_and_SSE/CAEP/RISC_Java_implementation) by Matt Domsch
> Matt presented an overview of the OpenID Foundation Shared Signals and Events Working Group, and his implementation of the object model in an open source Java library at [https://github.com/sailpoint-oss/openid-sse-model/](https://github.com/sailpoint-oss/openid-sse-model/)* [Shared Signal and Events (SSE) working group](https://openid.net/wg/sse/) in the OpenID Foundation.
## FIDO
* [2021 FIDO Developer Challenge: Outcomes and Winners](https://fidoalliance.org/2021-fido-developer-challenge-outcomes-and-winners/)
1. Gold Winner – [Lockdrop](https://lockdrop.com/)
2. Silver Winner – [Shaxware](https://www.shaxware.com/)
3. Bronze Winner – SoundAuth ([Trillbit](https://www.trillbit.com/)
This year’s FIDO Developer Challenge reached a successful conclusion, with a ceremonial event during [Authenticate 2021](https://authenticatecon.com/event/authenticate-2021-conference/) of the ceremony is available now, and we’re pleased to share more detailed stories of the three finalists as well as the rest of the teams that made it to the final stage.
* [Integrating FIDO with Verifiable Credentials (8.30 am start)](https://iiw.idcommons.net/10E/_Integrating_FIDO_with_Verifiable_Credentials_(8.30_am_start)) by David Chadwick
* [The Use of FIDO2 and Verifiable Credentials (David Chadwick)](https://youtube.com/watch?v%3Dl3taGxBdrRU)
W3C Web Authentication (FIDO2) provides a mechanism for strong authentication whilst W3C Verifiable Credentials provide a mechanism for strong identification and authorisation. Together they make an unbeatable pair for identity management.
Prof. David Chadwick presented work on sharing W3C Verifiable Crendentials via FIDO2 key setup with issuers of credentials.  In a nutshell, the holder and issuer use the WebAuthN protocol to strongly authenticate before the issuer protects the credentials with its signature.  Upon providing credentials to a relying party, the issuer (acting in an IDP capacity, so they must be online) will verify the identity of the holder via FIDO2 WebAuthN so that the credentials (or selected claims in the credentials for selective disclosure) can be shared with the relying party.  Ephemeral keys are created to bind the holder with such credentials shared to the relying party/verifier.  The relying party/verifier can use X.509 certs to confirm that the issuer is valid by checking the signature on the derived credential from the holder.
* [Fido Passkey](https://www.pingidentity.com/en/resources/blog/post/how-fido-passkeys-accelerate-passwordless-future.html)
* * [What is FIDO? Infographic](https://www.scmagazine.com/resource/identity-and-access/what-is-fido)
- [How passkeys pave the way for passwordless authentication](https://www.scmagazine.com/resource/identity-and-access/how-passkeys-pave-the-way-for-passwordless-authentication)
* [FIDO: Everything You Need to Know About Fast Identity Online](https://www.pingidentity.com/en/company/blog/posts/2021/fast-identity-online-fido.html)
* [Use Fido2 Passwords Authentication with Azure AD](https://damienbod.com/2022/01/17/use-fido2-passwordless-authentication-with-azure-ad/) Damion Bod
This article shows how to implement FIDO2 passwordless authentication with Azure AD for users in an Azure tenant.
* [Charting an Accelerated Path Forward for Passwordless Authentication Adoption](https://fidoalliance.org/charting-an-accelerated-path-forward-for-passwordless-authentication-adoption/) FIDO
* [The paper introduces](https://media.fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-CasesFINAL.pdf) multi-device FIDO credentials, also informally referred to by the industry as “passkeys,” which enable users to have their FIDO login credentials readily available across all of the user’s devices.
* [FIDO passkeys are an existential threat to fintech startups](https://werd.io/2022/fido-passkeys-are-an-existential-threat-to-fintech-startups)
by definition, screen scraping requires storing a user’s financial system passwords in clear text. Nonetheless, you can bet that every system that integrates with payroll systems, and almost every system that integrates with banks (at a minimum), uses the technique. The US has badly needed [open banking style standards](https://standards.openbanking.org.uk/api-specifications/) for years.
* [FIDO Alliance Supports Biden Administration EO on Cybersecurity](https://fidoalliance.org/fido-alliance-supports-biden-administration-eo-on-cybersecurity/)
There have been a number of high profile attacks against critical American infrastructure in recent months, including the Solarwinds supply chain attack that exposed much of the government to potential risk. Top of mind in recent days is the ransomware attack against Colonial Pipeline, which significantly impacted the flow of refined oil across America. These attacks expose the vulnerability of critical infrastructure in the United States, and the Biden Administration is issuing federal directives that will minimize or eliminate risk.
## OAuth

37
identosphere-dump/open-standards/not-ssi/fido-alliance.md Normal file
View File

@ -0,0 +1,37 @@
# Fido Alliance
* [LoginWithFIDO.com](https://loginwithfido.com/)
* [Consumer Research](https://fidoalliance.org/consumerresearch/)
* [A WebAuthn Apache module?](https://hanszandbelt.wordpress.com/2022/05/05/a-webauthn-apache-module/) Hans Zandbelt
> any sensible WebAuthn/FIDO2 Apache module would rely on an externally running “Provider” software component to offload the heavy-lifting of onboarding and managing users and credentials.
* [2021 FIDO Developer Challenge: Outcomes and Winners](https://fidoalliance.org/2021-fido-developer-challenge-outcomes-and-winners/)
1. Gold Winner – [Lockdrop](https://lockdrop.com/)
2. Silver Winner – [Shaxware](https://www.shaxware.com/)
3. Bronze Winner – SoundAuth ([Trillbit](https://www.trillbit.com/)
This year’s FIDO Developer Challenge reached a successful conclusion, with a ceremonial event during [Authenticate 2021](https://authenticatecon.com/event/authenticate-2021-conference/) of the ceremony is available now, and we’re pleased to share more detailed stories of the three finalists as well as the rest of the teams that made it to the final stage.
* [Integrating FIDO with Verifiable Credentials (8.30 am start)](https://iiw.idcommons.net/10E/_Integrating_FIDO_with_Verifiable_Credentials_(8.30_am_start)) by David Chadwick
* [The Use of FIDO2 and Verifiable Credentials (David Chadwick)](https://youtube.com/watch?v%3Dl3taGxBdrRU)
W3C Web Authentication (FIDO2) provides a mechanism for strong authentication whilst W3C Verifiable Credentials provide a mechanism for strong identification and authorisation. Together they make an unbeatable pair for identity management.
Prof. David Chadwick presented work on sharing W3C Verifiable Crendentials via FIDO2 key setup with issuers of credentials.  In a nutshell, the holder and issuer use the WebAuthN protocol to strongly authenticate before the issuer protects the credentials with its signature.  Upon providing credentials to a relying party, the issuer (acting in an IDP capacity, so they must be online) will verify the identity of the holder via FIDO2 WebAuthN so that the credentials (or selected claims in the credentials for selective disclosure) can be shared with the relying party.  Ephemeral keys are created to bind the holder with such credentials shared to the relying party/verifier.  The relying party/verifier can use X.509 certs to confirm that the issuer is valid by checking the signature on the derived credential from the holder.
* [Fido Passkey](https://www.pingidentity.com/en/resources/blog/post/how-fido-passkeys-accelerate-passwordless-future.html)
* * [What is FIDO? Infographic](https://www.scmagazine.com/resource/identity-and-access/what-is-fido)
- [How passkeys pave the way for passwordless authentication](https://www.scmagazine.com/resource/identity-and-access/how-passkeys-pave-the-way-for-passwordless-authentication)
* [FIDO: Everything You Need to Know About Fast Identity Online](https://www.pingidentity.com/en/company/blog/posts/2021/fast-identity-online-fido.html)
* [Use Fido2 Passwords Authentication with Azure AD](https://damienbod.com/2022/01/17/use-fido2-passwordless-authentication-with-azure-ad/) Damion Bod
This article shows how to implement FIDO2 passwordless authentication with Azure AD for users in an Azure tenant.
* [Charting an Accelerated Path Forward for Passwordless Authentication Adoption](https://fidoalliance.org/charting-an-accelerated-path-forward-for-passwordless-authentication-adoption/) FIDO
* [The paper introduces](https://media.fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-CasesFINAL.pdf) multi-device FIDO credentials, also informally referred to by the industry as “passkeys,” which enable users to have their FIDO login credentials readily available across all of the user’s devices.
* [FIDO passkeys are an existential threat to fintech startups](https://werd.io/2022/fido-passkeys-are-an-existential-threat-to-fintech-startups)
by definition, screen scraping requires storing a user’s financial system passwords in clear text. Nonetheless, you can bet that every system that integrates with payroll systems, and almost every system that integrates with banks (at a minimum), uses the technique. The US has badly needed [open banking style standards](https://standards.openbanking.org.uk/api-specifications/) for years.
* [FIDO Alliance Supports Biden Administration EO on Cybersecurity](https://fidoalliance.org/fido-alliance-supports-biden-administration-eo-on-cybersecurity/)
There have been a number of high profile attacks against critical American infrastructure in recent months, including the Solarwinds supply chain attack that exposed much of the government to potential risk. Top of mind in recent days is the ransomware attack against Colonial Pipeline, which significantly impacted the flow of refined oil across America. These attacks expose the vulnerability of critical infrastructure in the United States, and the Biden Administration is issuing federal directives that will minimize or eliminate risk.

6
identosphere-dump/open-standards/not-ssi/id-not-ssi.md
View File

@ -78,12 +78,6 @@ Democrats who have been misguidedly attacking Section 230 of the Communications
Like the "close" buttons for elevator doors, "keep me logged in" options on web-site authentication screens feel more like a placebo than something that actually works. Getting rid of passwords will mean we need to authenticate less often, or maybe just don't mind as much when we do.
* [Getting Started with Ceramic](https://blog.ceramic.network/getting-started-with-ceramic/)
In this beginner-friendly guide, I'll give you all the tools and knowledge needed to integrate the [Ceramic Network](https://developers.ceramic.network/) into your Web 3 [dapps](https://ethereum.org/en/dapps/).
The Ceramic Network is a decentralized data network that aims to bring composable data to Web 3 dapps. There are many types of data that Ceramic can work with, but for this guide we can treat Ceramic like a decentralized NOSQL document database.
* [ADOPTING NEW TECH: HOW TO GIVE YOUR TEAM THE BEST CHANCES OF SUCCESS](https://www.theengineroom.org/adopting-new-tech-how-to-give-your-team-the-best-chances-of-success/) The Engine Room
From our past work in this area, we have seen that slow and steady wins the race: for new policies, practices, and technologies to become part of workflows, staff need to be able to learn how to use new tools and incorporate them into their daily work practices — and be supported in doing so.

32
identosphere-dump/standards-orgs/README.md → identosphere-dump/open-standards/standards-orgs.md
View File

@ -13,25 +13,10 @@ published: false
## Links
* [Decentralized Profiles group Nov 25th call](https://blog.ceramic.network/dprofiles-call-3/)
Every 6 weeks the at Ceramic meets
* [Digital Identity in response to COVID-19: DGX Digital Identity Working Group](https://www.tech.gov.sg/files/media/corporate-publications/FY2021/dgx_2021_digital_identity_in_response_to_covid-19.pdf)
## ITU-T
## OpenSSF
* [Digital Identity Attestation Roundup - Open Source Security Foundation](https://openssf.org/blog/2021/01/27/digital-identity-attestation-roundup/%23)
We kicked off the first Digital Identity Attestation Working Group meeting under the OpenSSF in August, 2020. The objective of this working group is to enable open source maintainers, contributors and end-users to understand and make decisions on the provenance or origin of the code they maintain, produce and use.
* [Digital Identity WG (September 30, 2020)](https://www.youtube.com/watch?t%3D648%26v%3D6Ym5bXRuzZ8%26feature%3Dyoutu.be)
## CASA
* [Chain Agnostic Standards Alliance](https://github.com/ChainAgnostic/CASA)
> The Chain Agnostic Standards Alliance (CASA) is a collection of working groups dedicated blockchain protocol-agnostic standards. CASA also publishes [Chain Agnostic Improvement Proposals](https://github.com/ChainAgnostic/CAIPs) which describe standards created by the different working groups.
## OASIS
* [OASIS Open Establishes European Foundation to Advance Open Collaboration Opportunities](https://www.oasis-open.org/2021/01/20/oasis-open-establishes-european-foundation-to-advance-open-collaboration-opportunities/)
@ -155,3 +140,18 @@ there are statements like: "Buy our products! We're the best!" (with nothing els
* [https://www.w3.org/2019/did-wg/](https://www.w3.org/2019/did-wg/) - Website
* [https://lists.w3.org/Archives/Public/public-did-wg/](https://lists.w3.org/Archives/Public/public-did-wg/) - LIst Archives
## Other
### OpenSSF
* [Digital Identity Attestation Roundup - Open Source Security Foundation](https://openssf.org/blog/2021/01/27/digital-identity-attestation-roundup/%23)
We kicked off the first Digital Identity Attestation Working Group meeting under the OpenSSF in August, 2020. The objective of this working group is to enable open source maintainers, contributors and end-users to understand and make decisions on the provenance or origin of the code they maintain, produce and use.
* [Digital Identity WG (September 30, 2020)](https://www.youtube.com/watch?t%3D648%26v%3D6Ym5bXRuzZ8%26feature%3Dyoutu.be)
### CASA
* [Chain Agnostic Standards Alliance](https://github.com/ChainAgnostic/CASA)
> The Chain Agnostic Standards Alliance (CASA) is a collection of working groups dedicated blockchain protocol-agnostic standards. CASA also publishes [Chain Agnostic Improvement Proposals](https://github.com/ChainAgnostic/CAIPs) which describe standards created by the different working groups.

64
identosphere-dump/open-standards/standards.md
View File

@ -4,7 +4,6 @@ published: false
# Standards
* [DIDs are not enough - we need an Authoriziation standard too](https://medium.com/energy-web-insights/api-access-security-for-dapps-cfcfa928623c) Energy Web
If you are a developer and want to write a DApp [...] you probably are using API-Keys in your front-end. If this is the case, then you should consider the security risk the publication of the API-Key in your front end represents and ask yourself if it would make sense to switch to a user authentication scheme.
@ -40,40 +39,7 @@ Here’s my premise – we don’t have standards nor interoperability – at le
* [Manifesto: Rules for standards-makers](http://scripting.com/2017/05/09/rulesForStandardsmakers.html)
> I've used all kinds of formats and protocols in a long career as a software developer, even created a few. My new manifesto summarizes what I've learned about what works and what doesn't.
## Formal Objection
* [Re: historical background regarding success of responses to formal objections](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0076.html) Liam R. E. Quin (Monday, 13 September)
> In the 17 years i worked at W3C, the formal objections were
>
> (1) "we [the objector] wanted to be on record as saying this but go ahead and publish" (the most common);\
> (2) we [the objector] have a product, or are about to ship a product, and the feature(s) in  this spec would cause problems in the short-term for our product, and that's more important to us than the Web (no-one will ever admit to this but it's not uncommon)\
> (3) we object to this spec, we prefer another approach, so here's a bunch of fake objections to slow things down because we can't share our actual business strategy\
> (4) we believe there's a technical problem with this spec, but we didn't notice it over the past four years despite a last call  review (this one is actually rare but does happen)\
## New
* [What's New in Passwordless Standards, 2021 edition!](https://techcommunity.microsoft.com/t5/identity-standards-blog/what-s-new-in-passwordless-standards-2021-edition/ba-p/2124136) (Microsoft)
> The Web Authentication API (WebAuthn) Level 2 specification is currently a Candidate Recommendation at the W3C. "Level 2" essentially means major version number 2.
>
> The version 2.1 of the[Client to Authenticator Protocol (CTAP)](https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html) specification is a Release Draft at the FIDO Alliance. This means the spec is in a public review period before final publication.
> We think you might want to hear about what we think is especially fun about WebAuthn L2 and CTAP 2.1.
## Big Pic
* [Decentralised Identity: What’s at Stake?](https://inatba.org/wp-content/uploads/2020/11/2020-11-INATBA-Decentralised-Identity-001.pdf) A Position Paper by the INATBA Identity Working Group
> INATBA has a specific Standards Committee to liaison with relevant standardisation committees and bodies. Some relevant standardisation committee and bodies include:
> - [ISO/TC 307 “Blockchain and distributed ledger technologies”](https://www.iso.org/committee/6266604.html)
> - [CEN/CENELEC JTC 19 “Blockchain and Distributed Ledger Technologies”](https://standards.iteh.ai/catalog/tc/cen/d96ab6b7-aac8-49e9-9ac5-b391bbd2abdc/cen-clc-jtc-19)
> - [Decentralised Identifiers (DIDs)](https://w3c.github.io/did-core/)
> - [DID Resolution](https://w3c-ccg.github.io/did-resolution/)
> - [Verifiable Credentials (VCs)](https://www.w3.org/TR/vc-data-model/)
> - “[Issuer](https://github.com/w3c-ccg/vc-issuer-http-api)” and “[Verifier](https://github.com/w3c-ccg/vc-verifier-http-api)” API, [​Linked Data Vocabulary](https://digitalbazaar.github.io/citizenship-vocab/)
> - [Credential Handler API](https://w3c-ccg.github.io/credential-handler-api/)
> - [DID SIOP](https://identity.foundation/did-siop/)
> - [DID Comm](https://github.com/decentralized-identity/didcomm-messaging)
> - [Trust over IP Foundation](https://trustoverip.org/)
* [distributed ID learning path](https://translate.google.com/translate?sl=auto&tl=en&u=https://kristinayasuda.com/posts/decentralized-identity-catch-up-path/) Christina Yasuda based on [VC-Spec](https://github.com/decentralized-identity/vc-spec-map) Map by Michael Ruminer
> first describes pre-requisite knowledge, including JSON, JSON-LD, JWT, JWS, JWK, JWA, and sometimes CBOR. She then goes on to break down knowledge areas beginning with the basics: DID-Core, DID-Resolution, DID-Spec, DID Use-Cases. Next, she covers Verifiable Credentials with VC-Data Model, VC Use-Cases, and VC-Implementors Guide, and also Transport, Credential Presentation, and Other Data Formats.
* [Linked Data Security](https://lists.w3.org/Archives/Public/public-credentials/2021Feb/0134.html) ([slide deck](https://lists.w3.org/Archives/Public/public-credentials/2021Feb/att-0134/2021-Linked-Data-Security.pdf)
> The attached slide deck provides a basic overview (with examples) of Linked Data Security as well as the specifications in that orbit. The W3C CCG is  actively developing a number of these specifications.
* [Roadmap: Verifiable Trust Standards](https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0014.html)
@ -83,36 +49,6 @@ Here’s my premise – we don’t have standards nor interoperability – at le
> Red - Low-level cryptographic primitives
> Purple - General crypto packaging/protocol standards
> Orange - Application layer standards
* [An overview of blockchain technical standards](https://www.weforum.org/whitepapers/global-standards-mapping-initiative-an-overview-of-blockchain-technical-standards)
> This October report is the most comprehensive review of global standards around blockchain tech that we’ve seen. Here’s a list of standards bodies included in a chart towards the end:
> - [IEEE](https://standards.ieee.org/) (IoT; Cryptocurrency exchange & payment; tokens; energy; digital assets)
> - [ISO](https://www.iso.org/standards.html) (Security; identity)
> - [W3C](https://www.w3.org/standards/) (Identity)
> - [IRTF](https://irtf.org/) (Identity; digital assets)
> - [IEC](https://www.iec.ch/) (IoT)
> - [IETF](https://www.ietf.org/standards/) (Cryptocurrency payment)
> - [ITU-T](https://www.itu.int/en/ITU-T/publications/Pages/default.aspx) (Security; IoT; identity; DLT requirements)
> - [BSI](https://www.bsigroup.com/en-GB/standards/) (DLT requirements)
> - [CEN](https://www.cen.eu/Pages/default.aspx); [CENELEC](https://www.cenelec.eu/) (Security)
> - [Standards Australia](https://www.standards.org.au/) (Security; DLT taxonomy)
> - [WIPO](http://www.wipo.int/) (Blockchain for intellectual property)
> - [ETSI](https://www.etsi.org/standards) (Permissioned ledgers)
> - [SAC](http://www.sac.gov.cn/sacen/) (DLT requirements)
> - [BRIBA](https://www.beltandroadblockchain.org/) (DLT requirements)
> - [CESI](http://www.cc.cesi.cn/english.aspx) (Tokens; security)
> - [DCSA](https://dcsa.org/) (Interoperability)
> - [International Chamber of Commerce](https://iccwbo.org/) (Interoperability)
> - [EEA](https://entethalliance.org/) (Interoperability; tokens)
> - [Hyperledger](https://www.hyperledger.org/) (Interoperability; tokens)
> - [IWA](https://interwork.org/) (Tokens; analytics)
> - [JWG](https://intervasp.org/) (Tokens)
> - [National Blockchain and Distributed Accounting Technology Standardization Technical Committee](https://tech.sina.com.cn/it/2018-05-10/doc-ihaichqz3607998.shtml) (DLT requirements\terminology)
> - [CDC](https://digitalchamber.org/initiatives/) (Digital assets)
> - [MOBI](https://dlt.mobi/) (Vehicle identity; usage-based insurance; electric vehicle grid integration; connected mobility and data marketplace; supply chain and finance; securitization and smart contracts)
> - [GDF](https://www.gdfi.io/) (DLT requirements)
> - [BIG](https://blockchainindustrygroup.org/) (DLT requirements)
> - [BIA](https://bialliance.io/) (Interoperability)
> - [BiTA](https://www.bita.studio/) (Interoperability; DLT requirements)
### Verifier Universal Interface
* [Verifier Universal Interface by Gataca España S.L.](https://essif-lab.eu/verifier-universal-interface-by-gataca-espana-s-l/)

2
identosphere-dump/open-standards/verifiable-credentials.md
View File

@ -119,3 +119,5 @@ We design, implement, and evaluate a solution for achieving continuous authoriza
> So what’s the problem? I can say with full confidence after years of experience building and deploying systems to support parameterized scopes like this that they are fragile, awkward, and lead to insecure corner cases.
* [Bikeshed: Renaming the VC HTTP API](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0131.html)  Manu Sporny (Saturday, 17 July)
> the fundamental issue is that stringing a bunch of consonants together ("HTTP") rarely leads to something easy to say in conversation.
* [Identity, Unlocked... Explained: Season 2, Ep. 2](https://auth0.com/blog/identity-unlocked-explained-season-2-ep-2/) Vittorio Bertocci with Filip Skokan
> a conversation about a few three-letter extensions to OAuth (which, incidentally, would also fit well in a pirate incantation!): PAR, RAR, and JAR. Filip is a Senior Engineer II at Auth0, the author of a popular book on open source identification, and a contributor to both the [IETF](https://www.ietf.org/) and the [OpenID Foundation](https://openid.net/foundation/).