mirror of
https://github.com/Decentralized-ID/decentralized-id.github.io.git
synced 2024-12-12 00:54:23 -05:00
more sorting :D
This commit is contained in:
⧉ infominer
parent
e97c49bc62
commit
d758abd73d
@ -4,8 +4,16 @@ layout: single
|
||||
published: false
|
||||
---
|
||||
|
||||
|
||||
- [Mike Jones’ Blog](https://self-issued.info/)
|
||||
- [Nat Sakimura’s Blog](https://nat.sakimura.org/)
|
||||
- [John Bradley’s Blog](https://www.thread-safe.com/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eventually there will be a section with individual pages for the various influential and\or prominent members of the DID\SSI community. But I wasn't sure where to start...
|
||||
|
||||
I decided to start by featuring Women in Identity first, and expand from there.
|
||||
|
||||
@ -48,7 +48,7 @@
|
||||
- ISO/IEC
|
||||
- ISO Standards
|
||||
- mDL 18013-5 ✓
|
||||
- 22030 ✓
|
||||
- 22030
|
||||
- Working Group 3 - Travel Documents
|
||||
- Non SSI Identity Standards
|
||||
- OpenID
|
||||
@ -93,8 +93,8 @@
|
||||
- DIACC ✓
|
||||
- ID2020 ✓
|
||||
- OpenID Foundation ✓
|
||||
- M2B Alliance (has a new name)
|
||||
- GLEIF
|
||||
- M2B Alliance (has a new name) ✓
|
||||
- GLEIF ✓
|
||||
- SSI Networks
|
||||
- DismeID
|
||||
- Sovrin
|
||||
|
||||
@ -6,13 +6,6 @@ published: false
|
||||
## Identosphere
|
||||
We created an [Identosphere Group on Tru.net](https://tru.net/Identosphere)
|
||||
|
||||
## Projects
|
||||
|
||||
RIF Identity
|
||||
|
||||
* [@ilanolkies](https://twitter.com/ilanolkies) shares: *Okey, so, today I mapped the work done in the last 3 month by [@rif_os](https://twitter.com/rif_os) about Self-Sovereign Identity protocols in a single link [https://github.com/rsksmart/rif-identity](https://github.com/rsksmart/rif-identity). All compatible with existent protocols and fully integrated into [@RSKsmart](https://twitter.com/RSKsmart) blockchain. The future is one step closer.*
|
||||
|
||||
|
||||
## History
|
||||
|
||||
* [A brief history of SSI: Where does it come from? A timeline.](https://jolocom.io/blog/a-brief-history-of-ssi-where-does-it-come-from-a-timeline/)
|
||||
|
||||
@ -1,5 +1,11 @@
|
||||
# IAM Companies
|
||||
|
||||
|
||||
* [@open_measure](https://twitter.com/open_measure) · [44m](https://twitter.com/open_measure/status/1398540528090759170)
|
||||
|
||||
Our #IAM #VendorManagement database just exceeded the 100 entries threshold! There's still a lot of work but it shows already how the IAM #market is a vibrant, diverse, and innovative industry - find out more and contribute at [https://open-measure.atlassian.net/wiki/spaces/VEN/pages/195133452/Vendor+Database](https://open-measure.atlassian.net/wiki/spaces/VEN/pages/195133452/Vendor%2BDatabase)
|
||||
|
||||
|
||||
### Identos
|
||||
|
||||
* [Identos builds Verifiable Credentials into updated federated digital ID API](https://www.biometricupdate.com/202209/identos-builds-verifiable-credentials-into-updated-federated-digital-id-api) Biometric Update
|
||||
|
||||
@ -14,6 +14,8 @@ Today, we're taking a significant step forward — I'd go so far to call it a "l
|
||||
* [Okta Signs Definitive Agreement to Acquire Auth0](https://auth0.com/blog/okta-auth0-announcement/)
|
||||
|
||||
Auth0 will operate as an independent unit inside of Okta, and both platforms will be supported and invested in. As a result, organizations will have a wider breadth of identity solutions to fit their unique needs. Okta and Auth0’s comprehensive, complementary identity platforms are robust enough to serve the world’s largest organizations and flexible enough to address every identity use case, regardless of the audience or user.
|
||||
* [Implement Client Credentials with Kong Konnect and Okta](https://developer.okta.com/blog/2021/05/25/client-credentials-kong-konnect)
|
||||
> The OIDC plugin enables Kong, as the API gateway, to communicate with Okta via the OAuth/OIDC flows.
|
||||
|
||||
### Kuppinger Cole Comment: [Okta & Auth0](https://www.kuppingercole.com/blog/tolbert/okta-auth0)
|
||||
|
||||
|
||||
@ -10,39 +10,41 @@
|
||||
- Apple
|
||||
- Google
|
||||
|
||||
### Exostar
|
||||
### RIF Identity
|
||||
|
||||
* [Exostar Receives Kantara Initiative’s Identity Assurance Trust Framework Certification](https://www.exostar.com/press/exostar-receives-kantara-initiatives-identity-assurance-tKABNKABNrust-framework-certification-achieves-healthcare-and-life-science-community-milestones/) - Latest Recognition Further Demonstrates Company Protects Customers’ Identity and Personal Data by Complying with NIST 800-63 Standard
|
||||
> “This is a significant achievement and market differentiator for Exostar. The Kantara assessment and review process is rigorous and approval demonstrates a company’s care and respect for its customers.”
|
||||
|
||||
* [Webinar Series: rlogin Developer Workshop from RIF Identity](https://www.youtube.com/watch?v%3Do35EgZ4VH2Q)
|
||||
> rLogin allows web application developers to integrate blockchain technologies giving the user the power of data portability. After integrating rLogin you achieve:
|
||||
|
||||
- A back-end authenticating users by their wallet addressed - their Decentralized Identifiers.
|
||||
- A registration model capable of requesting users for data stored in its user-centric cloud storage, the Data Vault.
|
||||
- A front-end capable of interacting with any wallet that the user chooses, with a pre-designed user experience for registration and login.
|
||||
- Compatibility with a unified platform where the user can control their identity and information, the RIF Identity Manager.
|
||||
* [RIF’s Self Sovereign Identity Developer Library and Repos](https://rsci.app.link/)
|
||||
- [RSK ID Repos](https://developers.rsk.co/rif/identity/#repos)
|
||||
- [RIF Identity Documentation](https://developers.rsk.co/rif/identity/)
|
||||
* [Roadmap to Institutional Adoption of DeFi](https://www.youtube.com/watch?v%3DbkOQHcVVGoE) RSK - Coinfirm
|
||||
> The most recent FATF updated draft guidance from March 2021 introduces significant changes to the legal definition of DeFi platforms, expanding the types of entities that fall under FATF's umbrella. In this guidance, FATF defines most operators of decentralized finance platforms as “Virtual Asset Service Providers” that have AML/CFT obligations.
|
||||
* [@ilanolkies](https://twitter.com/ilanolkies) shares: *Okey, so, today I mapped the work done in the last 3 month by [@rif_os](https://twitter.com/rif_os) about Self-Sovereign Identity protocols in a single link [https://github.com/rsksmart/rif-identity](https://github.com/rsksmart/rif-identity). All compatible with existent protocols and fully integrated into [@RSKsmart](https://twitter.com/RSKsmart) blockchain. The future is one step closer.*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
|
||||
* [@open_measure](https://twitter.com/open_measure) · [44m](https://twitter.com/open_measure/status/1398540528090759170)
|
||||
|
||||
Our #IAM #VendorManagement database just exceeded the 100 entries threshold! There's still a lot of work but it shows already how the IAM #market is a vibrant, diverse, and innovative industry - find out more and contribute at [https://open-measure.atlassian.net/wiki/spaces/VEN/pages/195133452/Vendor+Database](https://open-measure.atlassian.net/wiki/spaces/VEN/pages/195133452/Vendor%2BDatabase)
|
||||
|
||||
|
||||
### itheum
|
||||
* [5 Reasons Why Our NFMe ID is a Game Changer](https://itheum.medium.com/5-reasons-why-our-nfme-id-is-a-game-changer-6e07d704ebae) • [kabnItheum](https://www.itheum.io/)
|
||||
|
||||
When “leased out”, the other party can access your personal data — in this manner, the NFMe ID acts as an “authorization key” that allows third parties to use your data in a fair way to generate a shared value between the third party and the owner of the data.
|
||||
|
||||
|
||||
|
||||
### Dhiway
|
||||
Video: [#MARK Studio - Create tamper-proof, secure and globally verifiable digital credentials instantly](https://www.youtube.com/shorts/ZAbiQci1x9w) Dhiway Networks
|
||||
|
||||
|
||||
### 5ire
|
||||
|
||||
- [Proof ID and Self Sovereign Identity](https://www.digitaljournal.com/pr/proof-id-and-self-sovereign-identity) by [5ire](https://5ire.org/) we can’t find out much about them
|
||||
- [Daon Provides Biometric Authentication for African Blockchain Identity Platform](https://findbiometrics.com/daon-provides-biometric-authentication-african-blockchain-identity-platform-06100/)
|
||||
|
||||
|
||||
## Centre (verite)
|
||||
* [Verite: Growing a Decentralized Identity Ecosystem](https://www.centre.io/blog/verite-growing-a-decentralized-identity-ecosystem) Centre Consortium
|
||||
|
||||
Developed last year and launched in Q1 of 2022, the [Verite standard](https://verite.id/verite) welcomes this flourishing of products and experiments with Verifiable Credentials and other privacy-preserving, data-minimizing patterns and principles.
|
||||
@ -51,6 +53,13 @@ Developed last year and launched in Q1 of 2022, the [Verite standard](https://ve
|
||||
|
||||
But as the world shifts to an increasingly digital native format, and as people take more ownership over their identity, how can the issuance of, presentation of, and verification of credentials be managed?
|
||||
|
||||
|
||||
|
||||
### Exostar
|
||||
|
||||
* [Exostar Receives Kantara Initiative’s Identity Assurance Trust Framework Certification](https://www.exostar.com/press/exostar-receives-kantara-initiatives-identity-assurance-tKABNKABNrust-framework-certification-achieves-healthcare-and-life-science-community-milestones/) - Latest Recognition Further Demonstrates Company Protects Customers’ Identity and Personal Data by Complying with NIST 800-63 Standard
|
||||
> “This is a significant achievement and market differentiator for Exostar. The Kantara assessment and review process is rigorous and approval demonstrates a company’s care and respect for its customers.”
|
||||
|
||||
### SICPA
|
||||
Short promo User Journey videos
|
||||
|
||||
|
||||
6
_posts/identosphere-dump/companies/google.md
Normal file
6
_posts/identosphere-dump/companies/google.md
Normal file
@ -0,0 +1,6 @@
|
||||
# Google
|
||||
|
||||
* [Announcing Schema Markup Validator: validator.schema.org (beta)](http://blog.schema.org/2021/05/announcing-schema-markup-validator.html)
|
||||
|
||||
SDTT is a tool from Google which began life as the [Rich Snippets Testing Tool](https://developers.google.com/search/blog/2010/09/rich-snippets-testing-tool-improvements) back in 2010. Last year Google [announced plans](https://developers.google.com/search/blog/2020/07/rich-results-test-out-of-beta) to migrate from SDTT to successor tooling, the [Rich Results Test](https://search.google.com/test/rich-results), alongside plans to "deprecate the Structured Data Testing Tool". The newer Google tooling is focused on helping publishers who are targeting specific schema.org-powered [searc](https://developers.google.com/search/docs/guides/search-gallery)[h features](https://www.blogger.com/) offered by Google, and for these purposes is a huge improvement as it contextualizes many warnings and errors to a specific target application.
|
||||
|
||||
@ -1,5 +1,13 @@
|
||||
# DOCK
|
||||
|
||||
|
||||
* [Dock DIDs Now Support Multiple Key Pairs](https://blog.dock.io/dids-multikey-support/) Dock
|
||||
|
||||
- Keys can be given different capabilities using Verification Relationships
|
||||
- We support 4 Verification Relationships: Authentication, Assertion, Key Agreement, and Capability Invocation.
|
||||
- DIDs can now be controlled by other DIDs
|
||||
- DIDs can now have service endpoints
|
||||
- Dock now supports off-chain DID Documents
|
||||
* [Web3 ID - Privacy-preserving user verification for Web3](https://www.dock.io/web3id) Dock
|
||||
> Web3 ID is a blockchain-based Authentication and Authorization system that puts user privacy first. Developers can grant access and verify end-user eligibility by requesting private data from users' non-custodial identity wallet apps. Always with the users’ consent.
|
||||
* [New Mobile Dock Wallet Release: Users Can Create and Manage Decentralized Identifiers (DIDs)](https://blog.dock.io/dock-wallet-did-management/) Dock
|
||||
|
||||
@ -1,5 +1,15 @@
|
||||
# trinsic
|
||||
|
||||
* [How Yoma Uses Trinsic to Help African Youth Build Digital CVs](https://trinsic.id/customer-story-yoma/)
|
||||
|
||||
Verifiable credentials is a beautiful set of technology that allows people and organizations to get the data in a verifiable form that still respects agency.”
|
||||
|
||||
Lohan Spies, Technical Lead, Yoma
|
||||
|
||||
* [Trinsic Builds Open Source Trust Registry Sponsored by eSSIF-Lab](https://trinsic.id/trinsic-builds-open-source-trust-registry-sponsored-by-essif-lab/) Trinsic
|
||||
|
||||
Driven by our motivation to make SSI more adoptable, we built the world’s first turn-key, open source trust registry solution. This work was sponsored by the [European Self-Sovereign Identity Framework Lab](https://essif-lab.eu/), which is an EU consortium that provides funding for projects that build SSI open source tools. Any ecosystem provider can use the trust registry implementation to enable governance in their verifiable data ecosystem.
|
||||
|
||||
* [Introducing Trinsic Ecosystems](https://trinsic.id/introducing-trinsic-ecosystems/)
|
||||
> Once an ecosystem is configured, providers need to onboard participants like issuers and verifiers. Trinsic Ecosystems comes with an API that’s extremely easy for any issuer or verifier to integrate and can be white-labeled with the name of the provider. In addition to the API, ecosystem participants can use the Trinsic Studio, a white-labeled web dashboard.
|
||||
* [Trinsic Year in Review 2020](https://trinsic.id/trinsic-in-2020-a-year-in-review/)
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
# Africa SSI Startups
|
||||
- [Daon Provides Biometric Authentication for African Blockchain Identity Platform](https://findbiometrics.com/daon-provides-biometric-authentication-african-blockchain-identity-platform-06100/)
|
||||
|
||||
### Diwala
|
||||
|
||||
|
||||
@ -34,3 +34,5 @@ Zain Yousaf, our Product Principal, and Marco took over to showcase Console to t
|
||||
|
||||
* [Selective Disclosure: Share What You Want](https://academy.affinidi.com/selective-disclosure-share-what-you-want-288f49e65680) Affinidi
|
||||
|
||||
|
||||
* [Explore Affinidi Schema Manager](https://ui.schema.affinidi.com/schemas/)
|
||||
|
||||
@ -17,3 +17,13 @@ These two international organizations are combining their talents to deliver SSI
|
||||
* [Issuing credentials directly to the MATTR mobile wallet](https://medium.com/mattr-global/issuing-credentials-directly-to-the-mattr-mobile-wallet-8e8cab931e2e) Mattr
|
||||
|
||||
If you’re already using a secure mechanism to authenticate your users, then setting up OIDC capability isn’t necessary. As we’ve explored, sending credentials using secure DID messaging directly or via a QR code or deep-link is safe, convenient and allows users to obtain their credentials directly.
|
||||
|
||||
* [Adding DID ION to MATTR VII](https://medium.com/mattr-global/adding-did-ion-to-mattr-vii-d56bdb7a2fde)
|
||||
> 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.
|
||||
|
||||
## Code
|
||||
|
||||
Code: [https://github.com/swiss-ssi-group/MattrGlobalAspNetCore](https://github.com/swiss-ssi-group/MattrGlobalAspNetCore)
|
||||
* [Present and and Verify Verifiable Credentials in ASP.NET Core Using Decentralized Identities and Mattr](https://damienbod.com/2021/05/10/present-and-verify-verifiable-credentials-in-asp-net-core-using-decentralized-identities-and-mattr/)
|
||||
|
||||
This article shows how use verifiable credentials stored on a digital wallet to verify a digital identity and use in an application. For this to work, a trust needs to exist between the verifiable credential issuer and the application which requires the verifiable credentials to verify. A blockchain decentralized database is used and MATTR is used as a access layer to this ledger and blockchain. The applications are implemented in ASP.NET Core.
|
||||
|
||||
@ -1,7 +1,5 @@
|
||||
# EU SSI Startups
|
||||
|
||||
https://essif-lab.eu/wp-content/uploads/2022/09/essif-booklet-22a.pdf
|
||||
|
||||
- GATTCA
|
||||
- MyDex
|
||||
- MeeCo
|
||||
@ -11,3 +9,20 @@ https://essif-lab.eu/wp-content/uploads/2022/09/essif-booklet-22a.pdf
|
||||
- Procivis
|
||||
+ Kilt
|
||||
+ Cheqd
|
||||
|
||||
## more
|
||||
|
||||
https://essif-lab.eu/wp-content/uploads/2022/09/essif-booklet-22a.pdf
|
||||
|
||||
[Ocean Protocol joins leading Web3 projects on the €20M+ Gaia-X moveID initiative to advance pan-European mobility](https://blog.oceanprotocol.com/ocean-protocol-joins-leading-web3-projects-on-the-20m-gaia-x-moveid-initiative-to-advance-72e4675d12d7) Ocean Protocol
|
||||
|
||||
Chainstep, Datarella, Fetch.ai, peaq and 51nodes
|
||||
|
||||
|
||||
|
||||
## Tangle Labs
|
||||
|
||||
* [Identity Manager – Self Sovereign Identity made Simple](https://tanglelabs.io/identity-manager-self-sovereign-identity-made-simple/) TangleLabs
|
||||
|
||||
By producing an accessible, open-source wrapper library, Tangle Labs provides any business or development team the opportunity to easily explore SSI and to test and prototype solutions that can bring added value to your business.
|
||||
|
||||
|
||||
@ -0,0 +1,11 @@
|
||||
# Ocean Protocol
|
||||
|
||||
* [Self-Sovereign Identity (SSI) and Verifiable Credentials (VC) in Ocean Protocol](https://port.oceanprotocol.com/t/proposal-walt-id-bringing-self-sovereign-identity-ssi-and-verifiable-credentials-vc-to-ocean-protocol-proof-of-concept/976)
|
||||
|
||||
What already exists, more recently: [fine-grained permissions 1](https://blog.oceanprotocol.com/fine-grained-permissions-now-supported-in-ocean-protocol-4fe434af24b9):
|
||||
|
||||
1. Marketplace-level fine-grained permissions for browsing, publishing, etc within a marketplace frontend
|
||||
2. Asset-level fine-grained permissions on consuming the asset itself
|
||||
* [Ocean Protocol joins leading Web3 projects on the €20M+ Gaia-X moveID initiative to advance pan-European mobility](https://blog.oceanprotocol.com/ocean-protocol-joins-leading-web3-projects-on-the-20m-gaia-x-moveid-initiative-to-advance-72e4675d12d7) Ocean Protocol
|
||||
|
||||
Ocean Protocol, the Web3 platform to unlock data services for AI and business innovation, has joined forces with Chainstep, Datarella, Fetch.ai, peaq and 51nodes to develop the system architecture for European mobility with the preservation of data autonomy as its core principle, within the Gaia-X moveID project.
|
||||
@ -4,6 +4,9 @@ published: false
|
||||
|
||||
# Explainer
|
||||
|
||||
* [Kaliya Young on Identikit with Michelle Dennedy](https://identitywoman.net/podcast-identikit-with-michelle-dennedy/)
|
||||
|
||||
our latest series examining the evolution of digital identity, and how self-sovereign identity, specifically, can advance a consent-based economy.
|
||||
* [The Architecture of Identity Systems](https://www.windley.com/archives/2020/09/the_architecture_of_identity_systems.shtml) by Phil Windley
|
||||
> I recently read a paper from Sam Smith, [Key Event Receipt Infrastructure](https://arxiv.org/abs/1907.02143), that provided inspiration for a way to think about and classify identity systems. In particular his terminology was helpful to me. This blog post uses terminology and ideas from Sam's paper to classify and analyze three different identity system architectures. I hope it provides a useful model for thinking about identity online.
|
||||
* [The SSO Practitioner’s Introduction to Decentralized Identity](https://www.pingidentity.com/en/resources/blog/post/sso-practitioners-introduction-decentralized-identity.html)
|
||||
@ -1253,7 +1256,16 @@ Oldie but Goodie by Kim Hamilton Duffy from when she worked at Learning Machines
|
||||
|
||||
Technically, Verifiable Claims are claims made about a “subject” (identified by a digital identifier such as a DID) that are rendered tamper proof through digital signatures. The authenticity of digital signatures may, in turn, be established through issuer identifiers, which may also be expressed as DIDs.
|
||||
|
||||
* [DID, in short for Decentralized Identifier, is basically a unique string of random numbers and letters](https://twitter.com/fennykyun/status/1564249472053514240) fennykyun
|
||||
> 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
|
||||
|
||||
* [Decentralized Systems of Identity and Owning Your Own Data](https://www.coindesk.com/podcasts/coindesks-money-reimagined/decentralized-systems-of-identity-and-owning-your-own-data/) Coindesk
|
||||
|
||||
On this episode of “Money Reimagined,” hosts [Michael Casey](https://twitter.com/mikejcasey) and [Sheila Warren](https://twitter.com/sheila_warren) are together again but this time, at Converge22 by Circle. They discuss the challenges of identity and verification in the U.S. and in other countries with [Daniel Buchner](https://www.linkedin.com/in/dbuchner/), head of decentralized identity at [Block](https://block.xyz/); and [Chi Nnadi](https://www.linkedin.com/in/chinnadi/?originalSubdomain%3Dke), the co-founder and CEO at [Mara](https://mara.xyz/).
|
||||
|
||||
* [Introduction to Decentralized Identity](https://wiki.iota.org/identity.rs/decentralized_identity) IOTA Wiki
|
||||
|
||||
|
||||
@ -11,3 +11,20 @@
|
||||
- Indy
|
||||
- Ursa
|
||||
- Other HyperLedger Projects
|
||||
|
||||
### DIF
|
||||
- Universal Resolver
|
||||
- [Exchange] DIDComm ✓ (DIF)
|
||||
- [Exchange] WACI-Pex ✓ (DIF)
|
||||
- [Complementary] KERI ✓ (DIF)
|
||||
- [Authorization] UCAN ✓ (DIF SDS-WG UCAN-WG)
|
||||
- [DataStores] EDV (DIF)
|
||||
- [DataStores] DWN (DIF)
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
* [New article about decentralized protocols to rule the world...](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0105.html)
|
||||
|
||||
* [Great Protocol Politics](https://foreignpolicy.com/2021/12/11/bitcoin-ethereum-cryptocurrency-web3-great-protocol-politics/) - The 21st century doesn’t belong to China, the United States, or Silicon Valley. It belongs to the internet.
|
||||
|
||||
@ -0,0 +1,5 @@
|
||||
# Torgap
|
||||
|
||||
* [Torgap architecture & products](https://github.com/BlockchainCommons/torgap)
|
||||
> Torgap is the Blockchain Commons security and privacy architecture model for creating gaps between connected apps and microservices. It supports privacy, service anonymity, identity psuedonymity, non-correlation, censorship-resistance, and seperation-of-interests and reduces single-points-of-failure. This emerging architecture is supported by QuickConnect and Blockchain Commons' Gordian system, while our Airgapped Wallet community and our research papers are charting its future.
|
||||
|
||||
@ -0,0 +1,19 @@
|
||||
# Sidetree
|
||||
* [Decoding the Sidetree Protocol](https://academy.affinidi.com/decoding-the-sidetree-protocol-18d8bfa39257) Affinidi
|
||||
> Sidetree protocols are layer 2 protocols that anchor to the underlying decentralized ledger system. That said, it is ledger agnostic and its primary role is to anchor batches of signed JSON operations to the network.
|
||||
* [Sidetree Protocol reaches V1](https://blog.identity.foundation/sidetree-protocol-reaches-v1/) DIF
|
||||
> This week, the DIF Steering Committee officially approved the first major release of the Sidetree Protocol specification, "v1" so to speak. This protocol has already been implemented, and four of its implementers have been collaborating intensively for over a year on expanding and extending this specification together.
|
||||
* [ION – We Have Liftoff!](https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-we-have-liftoff/ba-p/1441555)
|
||||
> We are excited to share that v1 of [ION](https://identity.foundation/ion/) is complete and has been launched on Bitcoin mainnet. We have deployed an ION node to our production infrastructure and are working together with other companies and organizations to do so as well. ION does not rely on centralized entities, trusted validators, or special protocol tokens – ION answers to no one but you, the community. Because ION is an open, permissionless system, anyone can run an ION node, in fact the more nodes in operation, the stronger the network becomes. Development of ION, and the Sidetree standard ION is based on, takes place in the [Decentralized Identity Foundation](https://identity.foundation/) (DIF). Read on to learn how you can integrate ION, DIDs, and Verifiable Credentials in your applications and services.
|
||||
|
||||
|
||||
### Well Known
|
||||
* [Link your domain to your Decentralized Identifier (DID) (preview)](https://docs.microsoft.com/en-us/azure/active-directory/verifiable-credentials/how-to-dnsbind)
|
||||
> We make a link between a domain and a DID by implementing an open standard written by the Decentralized Identity Foundation called [Well-Known DID configuration](https://identity.foundation/.well-known/resources/did-configuration/). The verifiable credentials service in Azure Active Directory (Azure AD) helps your organization make the link between the DID and domain by including the domain information that you provided in your DID, and generating the well-known config file:
|
||||
|
||||
|
||||
## Hub
|
||||
* [Selected Parts of the DIF SDS/CS Hub and EDV Discussion featuring Daniel Buchner’s Description of a Hub](https://hyperonomy.com/2021/03/24/transcription-of-selected-parts-of-the-dif-sds-cs-march-11-2021-zoom-call-hub-and-edv-discussion-featuring-daniel-buchners-description-of-a-hub/) Michael Herman
|
||||
> This is a [transcription of selected parts of the EDV-Hub conversation](https://hyperonomy.com/2021/03/24/transcription-of-selected-parts-of-the-dif-sds-cs-march-11-2021-zoom-call-hub-and-edv-discussion-featuring-daniel-buchners-description-of-a-hub/) during the DIF SDS/CS Thursday weekly Zoom call on March 11, 2021. This is the call where Daniel Buchner described (verbally) several aspects about what is and what is not a Hub.
|
||||
* [PROPOSAL: Confidential Storage Specification Refactoring 0.2 – March 24, 2021](https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0245.html)
|
||||
> Based on the March 11 Zoom discussion where we worked hard to discern the differences between Agents, Hubs, and EDVs (and I believe were largely successful IMO), I’ve like to propose to the SDS/CS WG that we refactor the current Confidential Storage specification into 3 separable parts/specifications.
|
||||
@ -1,32 +1,34 @@
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
### CCG
|
||||
* [Open API for Interoperable Traceability](https://w3c-ccg.github.io/traceability-interop/openapi/%23overview) CCG
|
||||
> `resolve:dids - Grants permission to resolve DIDsissue:credentials - Grants permission issue Verifiable Credentialsverify:credentials - Grants permission verify Verifiable Credentialsread:credentials - Grants permission to get Verifiable Credentialsupdate:credentials - Grants permission to update the status of Verifiable Credentialsprove:presentations - Grants permission to prove Verifiable Presentationsverify:presentations - Grants permission verify Verifiable Presentationssubmit:presentations - Grants permission to submit Verifiable Presentations`
|
||||
|
||||
# Tools
|
||||
## Schema
|
||||
|
||||
* [Announcing Schema Markup Validator: validator.schema.org (beta)](http://blog.schema.org/2021/05/announcing-schema-markup-validator.html)
|
||||
|
||||
SDTT is a tool from Google which began life as the [Rich Snippets Testing Tool](https://developers.google.com/search/blog/2010/09/rich-snippets-testing-tool-improvements) back in 2010. Last year Google [announced plans](https://developers.google.com/search/blog/2020/07/rich-results-test-out-of-beta) to migrate from SDTT to successor tooling, the [Rich Results Test](https://search.google.com/test/rich-results), alongside plans to "deprecate the Structured Data Testing Tool". The newer Google tooling is focused on helping publishers who are targeting specific schema.org-powered [search features](https://developers.google.com/search/docs/guides/search-gallery) offered by Google, and for these purposes is a huge improvement as it contextualizes many warnings and errors to a specific target application.
|
||||
|
||||
## JWT
|
||||
|
||||
* [Beginners Guide to JWTs](https://developer.okta.com/blog/2020/12/21/beginners-guide-to-jwt)
|
||||
> A JWT is a structured security token format used to encode JSON data. The main reason to use JWT is to exchange JSON data in a way that can be cryptographically verified. There are two types of JWTs:
|
||||
> - JSON Web Signature (JWS)
|
||||
> - JSON Web Encryption (JWE)
|
||||
> The data in a JWS is public—meaning anyone with the token can read the data—whereas a JWE is encrypted and private. To read data contained within a JWE, you need both the token and a secret key.
|
||||
|
||||
## Semantics
|
||||
* [The Importance of Data Inputs and Semantics for SSI with Paul Knowles [Podcast]](https://northernblock.io/semantics-for-ssi-with-paul-knowles/)
|
||||
> The platform was an incredibly federated platform when I built it because I didn’t know that SSI existed. So as soon as I found that ecosystem, I tore up the rulebook and said, “This isn’t going to work; I have to rebuild it.”
|
||||
* [Webinar Series: rlogin Developer Workshop from RIF Identity](https://www.youtube.com/watch?v%3Do35EgZ4VH2Q)
|
||||
> rLogin allows web application developers to integrate blockchain technologies giving the user the power of data portability. After integrating rLogin you achieve:
|
||||
|
||||
- A back-end authenticating users by their wallet addressed - their Decentralized Identifiers.
|
||||
- A registration model capable of requesting users for data stored in its user-centric cloud storage, the Data Vault.
|
||||
- A front-end capable of interacting with any wallet that the user chooses, with a pre-designed user experience for registration and login.
|
||||
- Compatibility with a unified platform where the user can control their identity and information, the RIF Identity Manager.
|
||||
* [What is the VC-Generator App and How to Leverage it?](https://academy.affinidi.com/what-is-the-vc-generator-app-and-how-to-leverage-it-4fa5a54844f2)
|
||||
> In simple terms, the VC-Generator allows you to choose a credential type that needs to be issued or verified from a drop-down list and displays the associated VC schema.
|
||||
|
||||
Code: [https://github.com/swiss-ssi-group/MattrGlobalAspNetCore](https://github.com/swiss-ssi-group/MattrGlobalAspNetCore)
|
||||
* [Present and and Verify Verifiable Credentials in ASP.NET Core Using Decentralized Identities and Mattr](https://damienbod.com/2021/05/10/present-and-verify-verifiable-credentials-in-asp-net-core-using-decentralized-identities-and-mattr/)
|
||||
* [https://github.com/transmute-industries/xmss](https://github.com/transmute-industries/xmss)
|
||||
|
||||
|
||||
This article shows how use verifiable credentials stored on a digital wallet to verify a digital identity and use in an application. For this to work, a trust needs to exist between the verifiable credential issuer and the application which requires the verifiable credentials to verify. A blockchain decentralized database is used and MATTR is used as a access layer to this ledger and blockchain. The applications are implemented in ASP.NET Core.
|
||||
* [Gordian QR Tool Supports Vaccine Records, 2FAs, Cryptoseeds, and More](https://www.blockchaincommons.com/projects/Releasing-QRTool/) Blockchain Commons
|
||||
> Some possible architectural issues arise from using QR codes for confidential data, such as the fact that you’re actually transmitting the data (not a proof of the data), that the QRs tend to contain all of the data (not just a selection), and that there’s no way to rescind a QR or expire it. Those issues will have to be dealt with at a foundational level as we figure out what can safely be encoded as a QR — and more importantly how to offer restricted proofs rather than complete information.
|
||||
* [Build an SSI proof of concept in <30 minutes](https://iiw.idcommons.net/21G/_Build_an_SSI_proof_of_concept_in_30_minutes) by Riley Hughes
|
||||
@ -231,10 +233,6 @@ This is so exciting to see what Wayne and his team are building.
|
||||
* [Status.trinsic.id](http://status.trinsic.id/)
|
||||
> View historical uptime: Using the status page, you can see the last 90 days of uptime of all our externally-facing services. You can also inspect individual incidents and view incident reports.Be notified of incidents: By clicking the “subscribe” button in the upper-left of the screen, you can have any downtime or incidents trigger a notification to your email or Slack workspace.
|
||||
|
||||
* [RIF’s Self Sovereign Identity Developer Library and Repos](https://rsci.app.link/)
|
||||
- [RSK ID Repos](https://developers.rsk.co/rif/identity/#repos)
|
||||
- [RIF Identity Documentation](https://developers.rsk.co/rif/identity/)
|
||||
|
||||
* [Transmute releases technical workbenches](https://medium.com/transmute-techtalk/transmute-releases-technical-workbenches-892f8140ac6e) by Orie Steele, Transmute
|
||||
> This new suite of tools is available for developers to experiment with today and includes:
|
||||
>
|
||||
@ -332,13 +330,6 @@ Whether a beginning learner, or interested in advanced concepts like Game Develo
|
||||
|
||||
DID method traits are testable properties about DID methods that can help implementers tame complexity and choose the right DID method(s) for their use case.
|
||||
|
||||
* [Indexing and Querying Revoked Verifiable Credentials](https://medium.com/51nodes/indexing-and-querying-revoked-verifiable-credentials-e229dc2781d4) 51 Nodes
|
||||
|
||||
this article describes a simple approach to revoke verifiable credentials and a decentralized and efficient way to index and query those revoked credentials using the [Graph protocol](https://thegraph.com/en/).
|
||||
|
||||
We consider the knowledge of Self-Sovereign Identity (SSI) and rudimentary knowledge of the [Ethr DID method](https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md) as a requirement for understanding this article.
|
||||
|
||||
|
||||
|
||||
* [Keep Badges Weird is about breaking boundaries: How the KBW community is convening systems](https://blog.weareopen.coop/keep-badges-weird-is-about-breaking-boundaries-42afb0415826) WeAreOpenCoop
|
||||
|
||||
|
||||
@ -0,0 +1,17 @@
|
||||
# Universal Resolver
|
||||
|
||||
* [Universal Resolver - resolve practically any DID](https://blog.identity.foundation/uni-resolver/) Identity Foundation
|
||||
> The Universal Resolver can now resolve 45 DID methods, and more are being added regularly. Visit [https://dev.uniresolver.io/](https://dev.uniresolver.io/) to see the full list of supported methods, and visit [this github page](https://github.com/decentralized-identity/universal-resolver/blob/main/docs/driver-development.md) to contribute a driver for a DID method.
|
||||
- [DID DIF Universal Resolver](https://dev.uniresolver.io/)
|
||||
* [Universal Resolver Driver Policy Discussion](https://iiw.idcommons.net/21P/_Universal_Resolver_Driver_Policy_Discussion) by Bernhard Fuchs, Markus Sabadello
|
||||
> The project has some guidelines for contributing new DID method drivers:[https://github.com/decentralized-identity/universal-resolver/blob/master/docs/driver-development.md](https://github.com/decentralized-identity/universal-resolver/blob/master/docs/driver-development.md)
|
||||
* [A Universal Resolver for self-sovereign identifiers](https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c)
|
||||
* [On any blockchain or other decentralized system](https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c) (Markus Sabadello)
|
||||
> This is a first step in fulfilling DIF’s mission to help individuals and organizations to control their digital identity, without being dependent on any intermediary party.
|
||||
>
|
||||
> This tool fulfills a similar purpose as Bind does in the DNS system: resolution of identifiers. However, instead of working with domain names, we work with self-sovereign identifiers that can be created and registered directly by the entities they refer to.
|
||||
* [Mission Accomplished: Universal Resolver Calls coming to an end](https://blog.identity.foundation/universal-resolver-calls-wrapup/) Identity Foundation
|
||||
> Considering that the group has accomplished these goals, there is currently no more need for dedicated calls. Work on the Universal Resolver work item will continue on Github (under the [Universal Resolver](https://github.com/decentralized-identity/universal-resolver) and [Identifiers &Discovery](https://github.com/decentralized-identity/identifiers-discovery/) and on DIF Slack in the Identifiers & Discovery Working Group channel, #wg-id.
|
||||
|
||||
- [jolocom/ddoresolver-rs](https://github.com/jolocom/ddoresolver-rs) github
|
||||
|
||||
@ -1,63 +1,78 @@
|
||||
# Open Standards
|
||||
# Web Standards
|
||||
|
||||
- Decentralized Identifier
|
||||
- Explainer
|
||||
- Methods
|
||||
- Resolution
|
||||
- Critique
|
||||
- Verifiable Credential
|
||||
- Explainer
|
||||
- Comparisons with/ other Tech
|
||||
- Varieties
|
||||
- JSON-LD
|
||||
- JSON-LD ZKP BBS+
|
||||
- JSON-JWT
|
||||
- ZKP-CL - [IIA] Indy Aries AnnonCreds
|
||||
- JWP
|
||||
- Exchange Protocols
|
||||
- DIDComm
|
||||
- CHAPI
|
||||
- OIDC
|
||||
- mDL
|
||||
- WACI-Pex
|
||||
- Complementary to VC/DID Standards
|
||||
- JSON-LD
|
||||
- JSON
|
||||
- KERI
|
||||
- Cryptography
|
||||
- BBS
|
||||
- Authorization Protocols
|
||||
- oCap/zCap
|
||||
- UCAN
|
||||
- GNAP
|
||||
- OAuth
|
||||
- Trust Frameworks
|
||||
- 800-63-3
|
||||
- DIACC
|
||||
- Blockchain Standards
|
||||
- ISOTC 307
|
||||
- CEN/EENTLIC
|
||||
- ERC 725
|
||||
- Standards Orgs
|
||||
- W3C
|
||||
- IETF
|
||||
- OASIS
|
||||
- ITU-T
|
||||
- ISO/IEC
|
||||
- ISO Standards
|
||||
- mDL 18013-5
|
||||
- 22030
|
||||
- Working Group 3 - Travel Documents
|
||||
- Non SSI Identity Standards
|
||||
- OpenID
|
||||
- FIDO
|
||||
- OAuth
|
||||
- SCIM
|
||||
- SAML
|
||||
- KMIP
|
||||
- Secure QR Code
|
||||
- Trust Registries & Directories
|
||||
- TRAIN
|
||||
- Data Stores
|
||||
- EDV
|
||||
- DWN
|
||||
## W3C
|
||||
|
||||
Decentralized Identifier ✓
|
||||
- Explainer ✓
|
||||
- Literature +
|
||||
- Methods ✓
|
||||
- Tools \ Services
|
||||
- Critique ✓
|
||||
|
||||
Verifiable Credential
|
||||
- Explainer ✓
|
||||
- Comparisons ✓
|
||||
- Varieties
|
||||
- JSON-LD
|
||||
- JSON-LD ZKP BBS+
|
||||
- JSON-JWT
|
||||
- ZKP-CL - [IIA] Indy Aries AnnonCreds
|
||||
- JWP
|
||||
|
||||
JSON-LD
|
||||
- [Complementary] JSON-LD ✓ (W3C)
|
||||
|
||||
### Credentials Community Group
|
||||
|
||||
- [Exchange] CHAPI ✓ (CCG)
|
||||
- [Complementary] Cryptography > BBS ✓ (CCG)
|
||||
- [Authorization] oCap/zCap ✓ (CCG)
|
||||
|
||||
### IETF
|
||||
|
||||
- [Complementary] (IETF)
|
||||
- [Authorization] GNAP ✓ (IETF)
|
||||
- [Authorization] OAuth ✓ (IETF)
|
||||
- [ID-Non-SSI] OAuth (IETF)
|
||||
- [ID-Non-SSI] SCIM (IETF)
|
||||
|
||||
### OASIS
|
||||
|
||||
- [ID-Non-SSI] SAML (OASIS)
|
||||
- [ID-Non-SSI] KMIP (OASIS)
|
||||
- [ID-Non-SSI] Secure QR Code (OASIS)
|
||||
|
||||
### ITU-T
|
||||
|
||||
- [ITU-T SG17 - Kantara initiative and ITU-T SG 17](https://www.itu.int/en/ITU-T/studygroups/2017-2020/17/Pages/default.aspx)
|
||||
|
||||
### ISO/IEC
|
||||
- mDL 18013-5 ✓ (ISO)
|
||||
- 22030 ?
|
||||
- Working Group 3 - Travel Documents
|
||||
|
||||
### OpenID Foundation
|
||||
- [Exchange] OIDC ✓ (OpenID)
|
||||
- [ID-Non-SSI] OpenID (OpenID)
|
||||
|
||||
### ISO
|
||||
- [Exchange] mDL ✓ (ISO)
|
||||
- [Blockchain] ISOTC 307 ✓ (ISO)
|
||||
|
||||
### DIACC
|
||||
|
||||
- [TrustFramework] [DIACC](https://diacc.ca/trust-framework/)
|
||||
|
||||
### NIST
|
||||
|
||||
- [TrustFramework] 800-63-3 ([NIST](https://pages.nist.gov/800-63-3/))
|
||||
|
||||
### CEN/CENTLIC
|
||||
- [Blockchain] CEN/CENTLIC ✓ (CEN)
|
||||
- [Blockchain] ERC 725 (ERC-EIP)
|
||||
|
||||
### FIDO
|
||||
- [ID-Non-SSI] FIDO (FIDO)
|
||||
|
||||
### NGI
|
||||
- [TrustRegistry] TRAIN ([NGI](https://www.ngi.eu/funded_solution/essi_ioc_38/))
|
||||
|
||||
@ -71,6 +71,7 @@ Updates on Kepler including implementing support for [CACAO-ZCAPs](https://githu
|
||||
|
||||
## UCAN
|
||||
|
||||
[ucan-wg](https://github.com/ucan-wg)
|
||||
* [Lightweight Credentials for Offers with UCAN](https://blog.fission.codes/lightweight-credentials-ucan/)
|
||||
|
||||
these are the types of use cases that we think can be created and enabled across the web as an open, interoperable standard. And some of it crosses into the work we're doing as [part of the Decentralized Identity Foundation](https://blog.fission.codes/fission-demo-day-may-2021/), too.
|
||||
|
||||
@ -73,3 +73,8 @@ The BBS+ signature will also soon be available in [Finema](https://finema.co/)
|
||||
|
||||
Currently, everyone waiting for [#AIP2](https://twitter.com/hashtag/AIP2), which enables [#BBS](https://twitter.com/hashtag/BBS)+ [#Signature](https://twitter.com/hashtag/Signature) in #SSI. Companies already implemented in their products, such as [@trinsic_id](https://twitter.com/trinsic_id) and [@mattrglobal](https://twitter.com/mattrglobal). But ZKP [#predicates](https://twitter.com/hashtag/predicates) are not supported by BBS+, so no ZKP age verification possible. Back to [#AnonCreds](https://twitter.com/hashtag/AnonCreds)?
|
||||
- [aries-rfcs/0646-bbs-credentials#drawbacks](https://github.com/hyperledger/aries-rfcs/tree/main/features/0646-bbs-credentials%23drawbacks)
|
||||
* [What BBS+ Means For Verifiable Credentials](https://www.youtube.com/watch?v%3DdXlRIrrb9f4) Evernym
|
||||
> In a recent Evernym blog post, [we discussed why BBS+ LD-Proofs](https://www.evernym.com/blog/bbs-verifiable-credentials/) are the privacy-preserving VC format that everyone should implement. In this webinar….
|
||||
> - A brief history of verifiable credential formats, and how a lack of convergence makes scale and interoperability an ongoing challenge
|
||||
> - How BBS+ Signatures are the breakthrough that combine the best of the JSON-LD and ZKP formats, while still allowing for selective disclosure and non-trackability
|
||||
> - The path forward: What remains to be done to fully converge on the BBS+ format
|
||||
|
||||
@ -1,250 +0,0 @@
|
||||
# Decentralized Identifier
|
||||
|
||||
* [W3C launches Decentralized Identifiers as a web standard](https://portswigger.net/daily-swig/w3c-launches-decentralized-identifiers-as-a-web-standard) in the Daily Swig: Cybersecurity news and views.
|
||||
|
||||
“I would summarize the overall impact of DIDs on cybersecurity as making digital signing and [encryption](https://portswigger.net/daily-swig/encryption) much more widely available than today’s conventional X.509-based public key infrastructure (PKI),” Drummond Reed, director of trust services at Avast
|
||||
* [W3C overrules objections by Google, Mozilla to decentralized identifier spec](https://www.theregister.com/2022/07/01/w3c_overrules_objections/) Oh no, he DIDn't in the Register
|
||||
> The [DID specification](https://www.w3.org/TR/did-core/%23introduction) describes a way to deploy a globally unique identifier without a centralized authority (eg, Apple [for Sign in with Apple](https://developer.apple.com/sign-in-with-apple/) as a verifying entity.
|
||||
* [Link your domain to your Decentralized Identifier (DID) (preview)](https://docs.microsoft.com/en-us/azure/active-directory/verifiable-credentials/how-to-dnsbind)
|
||||
> We make a link between a domain and a DID by implementing an open standard written by the Decentralized Identity Foundation called [Well-Known DID configuration](https://identity.foundation/.well-known/resources/did-configuration/). The verifiable credentials service in Azure Active Directory (Azure AD) helps your organization make the link between the DID and domain by including the domain information that you provided in your DID, and generating the well-known config file:
|
||||
|
||||
* [What is a DID? Part 1](https://www.youtube.com/watch?v%3DOYYtxVEra1c) XSL Labs
|
||||
* [Qu’est-ce qu’un DID? Partie 1](https://www.youtube.com/watch?v%3DVNLKufTDM4o) XSL Labs
|
||||
* [Decentralized Identity: Why Are DIDs The Future of Digital Identity Management?](https://elastos.info/decentralized-identity-dids/)
|
||||
> Why would you have 75 logins when you could have 1?
|
||||
* [A DIF & TOIP Joint Statement of Support for the Decentralized Identifiers (DIDS) V1.0 Specification Becoming A W3C Specification](https://trustoverip.org/blog/2021/10/29/a-dif-toip-joint-statement-of-support-for-the-decentralized-identifiers-dids-v1-0-specification-becoming-a-w3c-standard/).
|
||||
|
||||
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](https://w3c.github.io/did-test-suite/%23report-by-methods) 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](https://indicio.tech/indicios-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)](https://medium.com/uport/ens-names-are-decentralized-identifiers-dids-724f0c317e4b) 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](https://w3c-ccg.github.io/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](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf) (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the [SSL/TLS protocol](https://en.wikipedia.org/wiki/Transport_Layer_Security) for encrypted Web traffic (now the largest PKI in the world).
|
||||
* [Cryptography Review of W3C VC Data Model and DID Standards and Implementation Recommendations](https://www.linkedin.com/posts/aniljohn_cryptography-review-of-w3c-vc-and-w3c-did-ugcPost-6892250585652162560-OQ3Y) SRI International
|
||||
* [Adding DID ION to MATTR VII](https://medium.com/mattr-global/adding-did-ion-to-mattr-vii-d56bdb7a2fde)
|
||||
> 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
|
||||
|
||||
* [Objections overruled by W3C director approving the DIDCore specification as a W3C Recommendation](https://www.w3.org/2022/06/DIDRecommendationDecision.html) W3C
|
||||
|
||||
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
|
||||
|
||||
* [Decentralized Identifiers (DID) 1.0 specification approved as W3C Recommendation](https://blog.identity.foundation/w3cdidspec-2/) Identity Foundatoin
|
||||
|
||||
Announcing the [Decentralized Identifiers (DID) v1.0 specification](https://www.w3.org/TR/did-core/) 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.
|
||||
* [Decentralized Identifiers: Implications for Your Data, Payments and Communications](https://newsletter.impervious.ai/decentralized-identifiers-implications-for-your-data-payments-and-communications-2/) Impervious
|
||||
> Through the DID Specification, service endpoints and DIDComm, Impervious has interlaced DIDs with Bitcoin Lightning, IPFS, WebRTC and resilient relays to introduce a new peer-to-peer internet standard with practical applications for mitigating censorship and surveillance risk.
|
||||
* [Verification Patterns, Part 2](https://docs.centre.io/blog/verification-patterns-2) Verite
|
||||
|
||||
Part 2 of this 2-part series explains the [did:pkh](https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md)/[CACAO](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md%23simple-summary) 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
|
||||
|
||||
* [Cute Learning Thread](https://twitter.com/fennykyun/status/1564249472053514240) fennykyun
|
||||
|
||||
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
|
||||
|
||||
* [Universal Resolver - resolve practically any DID](https://blog.identity.foundation/uni-resolver/) Identity Foundation
|
||||
|
||||
The Universal Resolver can now resolve 45 DID methods, and more are being added regularly. Visit [https://dev.uniresolver.io/](https://dev.uniresolver.io/) to see the full list of supported methods, and visit [this github page](https://github.com/decentralized-identity/universal-resolver/blob/main/docs/driver-development.md) to contribute a driver for a DID method.
|
||||
* [Advancing digital identity through DID core specification](https://iohk.io/en/blog/posts/2022/09/08/advancing-digital-identity-through-did-core-specification/) IOHK
|
||||
|
||||
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.
|
||||
|
||||
* [DIDs in DPKI](https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/dids-in-dpki.md)
|
||||
- [jolocom/ddoresolver-rs](https://github.com/jolocom/ddoresolver-rs) github
|
||||
- [Rust implementation of the did:key method](https://crates.io/crates/did-key) creds to Tomislav Markovski.
|
||||
* [Universal Resolver Driver Policy Discussion](https://iiw.idcommons.net/21P/_Universal_Resolver_Driver_Policy_Discussion) by Bernhard Fuchs, Markus Sabadello
|
||||
> The project has some guidelines for contributing new DID method drivers:[https://github.com/decentralized-identity/universal-resolver/blob/master/docs/driver-development.md](https://github.com/decentralized-identity/universal-resolver/blob/master/docs/driver-development.md)
|
||||
- [DID test suite](https://github.com/w3c/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)](https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0017.html)
|
||||
> - 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?](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0056.html) (Monday, 10 January)
|
||||
|
||||
#didlang 0.3 includes support for round-robin, load-balanced DID Agent serviceEndpoint clusters. [Here's a demo](https://youtu.be/mf0aKLvJoCw)
|
||||
|
||||
* [W3C Decentralized Identifiers v1.0 is a W3C Proposed Recommendation](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0030.html) Manu Sporny (Tuesday, 3 August)
|
||||
|
||||
* [W3C Decentralized Identifiers v1.0 is a W3C Proposed Recommendation](https://www.w3.org/blog/news/archives/9179):
|
||||
|
||||
* [The published version that will be voted on by W3C Members can be found here](https://www.w3.org/TR/2021/PR-did-core-20210803/):
|
||||
|
||||
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:
|
||||
|
||||
* [DID 1.0 Comments / Meeting Minutes (was RE: Mozilla Formally Objects to DID Core)](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0135.html) John, Anil (Monday, 27 September)
|
||||
|
||||
* [https://www.w3.org/2021/09/21-did10-minutes.html](https://www.w3.org/2021/09/21-did10-minutes.html) is fascinating reading!
|
||||
|
||||
* [...] I can speak to the work of the DHS SVIP Program and our approach and perspective across our two work-streams that touch upon the two points.
|
||||
|
||||
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”
|
||||
|
||||
* “<cwilso> +1 to tantek's concern that governments are responding to lobbying attempts on non-interoperable methods”
|
||||
|
||||
* [Mozilla Formally Objects to DID Core](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0010.html) 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](https://www.w3.org/TR/did-core/%23dids-as-enhanced-urns), we specifically compare the DID spec to the *URN spec*, [RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141). In fact we deliberately patterned the [ABNF for DIDs](https://www.w3.org/TR/did-core/%23did-syntax) 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](https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml).
|
||||
|
||||
Now: guess how many URN namespaces have been registered with IANA?
|
||||
|
||||
- [SEVENTY*. Count em.](https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml)
|
||||
|
||||
I don't see anyone complaining about interoperability of URN namespaces. Amd RFC 8141 was published over four years ago.
|
||||
|
||||
* [Some questions regarding DID verification relationships](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0009.html) Dmitri Zagidulin (Thursday, 2 December)
|
||||
|
||||
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](https://datatracker.ietf.org/doc/html/rfc7517%23section-4.2)
|
||||
|
||||
* [DID press release and UNECE white paper](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0087.html) steve capell (Wednesday, 20 July)
|
||||
|
||||
great to see that press release at [https://www.w3.org/2022/07/pressrelease-did-rec.html.en](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](https://unece.org/trade/uncefact/guidance-material)
|
||||
|
||||
* [DID Press Release Testimonials](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0022.html) Zundel, Brent (Friday, 8 July)
|
||||
|
||||
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](https://www.w3.org/2019/03/pressrelease-webauthn-rec.html)
|
||||
|
||||
The testimonials may be submitted as a reply to this email.
|
||||
|
||||
DID Methods
|
||||
|
||||
* [Announcement: New DID Method Specification: did:object](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0067.html) (Tuesday, 14 December)
|
||||
|
||||
The publication of [this DID Method specification](https://github.com/mwherman2000/TrustedDigitalWeb/blob/master/specifications/did-methods/did-object.md) realizes, in large part, a 4-year quest (or should I say personal mission) to create a platform to Tokenize Every Little Thing (ELT).
|
||||
|
||||
* [Re: CCG Community opinions needed to define CCG scope (specifically re: did methods as work items)](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0376.html) Manu Sporny (Thursday, 26 August)
|
||||
|
||||
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).
|
||||
|
||||
* [DID methods as W3C standards - a happy compromise?](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0117.html) steve capell (Tuesday, 22 February)
|
||||
|
||||
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.
|
||||
|
||||
* [Cross border identity use case - which did methods?](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0016.html) steve capell (Sunday, 6 March)
|
||||
|
||||
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"?
|
||||
|
||||
|
||||
|
||||
DID:TAG[re: Using Email as an Identifier](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0065.html) Bob Wyman (Friday, 12 November)
|
||||
|
||||
My [did:tag](https://github.com/bobwyman/did_method_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
|
||||
|
||||
* [re: some thought after using did:web](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0031.html) Orie Steele (Wednesday, 5 January)
|
||||
|
||||
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:
|
||||
|
||||
* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/Ed25519KeyPair.ts#L78](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/Ed25519KeyPair.ts%23L78)
|
||||
|
||||
* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2018.ts](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2018.ts)
|
||||
|
||||
* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2020.ts](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2020.ts)
|
||||
|
||||
* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/JsonWebKey2020.ts](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/JsonWebKey2020.ts)
|
||||
|
||||
* [DID Web, OpenSSL and Certificate Authorities](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0078.html) Orie Steele (Thursday, 17 February)
|
||||
|
||||
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:jwk is reborn!](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0066.html) Orie Steele (Friday, 8 April)
|
||||
|
||||
* [https://github.com/w3c/did-spec-registries/pull/432](https://github.com/w3c/did-spec-registries/pull/432)
|
||||
|
||||
DID:KEY
|
||||
|
||||
* [did-key-creator published](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0061.html) Brent Shambaugh (Tuesday, 28 June)
|
||||
|
||||
I published a did:key creator at
|
||||
|
||||
* [https://www.npmjs.com/package/did-key-creator](https://www.npmjs.com/package/did-key-creator)
|
||||
|
||||
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](https://github.com/w3c-ccg/did-method-key) and [https://w3c-ccg.github.io/did-method-key/](https://w3c-ccg.github.io/did-method-key/) .
|
||||
|
||||
* [did:key DID Document generation algorithm feedback](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0016.html) Manu Sporny (Tuesday, 14 June)
|
||||
|
||||
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.
|
||||
|
||||
* [...] [https://github.com/w3c-ccg/did-method-key/pull/51](https://github.com/w3c-ccg/did-method-key/pull/51)
|
||||
|
||||
* [Current status of DID Core implementations (June 2021)](https://lists.w3.org/Archives/Public/public-did-wg/2021Jun/0012.html)
|
||||
|
||||
Our latest implementation report for DID Core is available here:
|
||||
|
||||
* [https://w3c.github.io/did-test-suite/#spec-statement-summary](https://w3c.github.io/did-test-suite/%23spec-statement-summary)
|
||||
|
||||
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?
|
||||
@ -124,3 +124,9 @@ The platform, Amnesty says, wasn’t merely a passive site with insufficient con
|
||||
|
||||
Under [federal rules](https://www.healthit.gov/buzz-blog/information-blocking/information-blocking-eight-regulatory-reminders-for-october-6th) taking effect Thursday, health care organizations must give patients unfettered access to their full health records in digital format. No more long delays. No more fax machines. No more exorbitant charges for printed pages.
|
||||
|
||||
## Known
|
||||
* [Known](https://withknown.com/) has supported [Indieweb](https://indieweb.org/) standards since the beginning, but Fediverse has been notably missing. I think that’s a big omission, but also not something I’ve had bandwidth to fix.
|
||||
* [Building ActivityPub into Known](https://werd.io/2021/building-activitypub-into-known) Ben Werdmüller
|
||||
* [ActivityPub support · Issue #2615 · idno/known · GitHub](https://github.com/idno/known/issues/2615%23issuecomment-991335313)
|
||||
|
||||
This issue now has a funding of 3004.5068 USD (3000.0 USD @ $1.0/USD) attached to it.
|
||||
@ -1,65 +0,0 @@
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
# Protocols
|
||||
|
||||
* [New article about decentralized protocols to rule the world...](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0105.html)
|
||||
|
||||
* [Great Protocol Politics](https://foreignpolicy.com/2021/12/11/bitcoin-ethereum-cryptocurrency-web3-great-protocol-politics/) - The 21st century doesn’t belong to China, the United States, or Silicon Valley. It belongs to the internet.
|
||||
|
||||
* [Torgap architecture & products](https://github.com/BlockchainCommons/torgap)
|
||||
> Torgap is the Blockchain Commons security and privacy architecture model for creating gaps between connected apps and microservices. It supports privacy, service anonymity, identity psuedonymity, non-correlation, censorship-resistance, and seperation-of-interests and reduces single-points-of-failure. This emerging architecture is supported by QuickConnect and Blockchain Commons' Gordian system, while our Airgapped Wallet community and our research papers are charting its future.
|
||||
|
||||
* [Selected Parts of the DIF SDS/CS Hub and EDV Discussion featuring Daniel Buchner’s Description of a Hub](https://hyperonomy.com/2021/03/24/transcription-of-selected-parts-of-the-dif-sds-cs-march-11-2021-zoom-call-hub-and-edv-discussion-featuring-daniel-buchners-description-of-a-hub/) Michael Herman
|
||||
> This is a [transcription of selected parts of the EDV-Hub conversation](https://hyperonomy.com/2021/03/24/transcription-of-selected-parts-of-the-dif-sds-cs-march-11-2021-zoom-call-hub-and-edv-discussion-featuring-daniel-buchners-description-of-a-hub/) during the DIF SDS/CS Thursday weekly Zoom call on March 11, 2021. This is the call where Daniel Buchner described (verbally) several aspects about what is and what is not a Hub.
|
||||
|
||||
## Assorted
|
||||
- [Mike Jones’ Blog](https://self-issued.info/)
|
||||
- [Nat Sakimura’s Blog](https://nat.sakimura.org/)
|
||||
- [John Bradley’s Blog](https://www.thread-safe.com/)
|
||||
* [Decoding the Sidetree Protocol](https://academy.affinidi.com/decoding-the-sidetree-protocol-18d8bfa39257) Affinidi
|
||||
> Sidetree protocols are layer 2 protocols that anchor to the underlying decentralized ledger system. That said, it is ledger agnostic and its primary role is to anchor batches of signed JSON operations to the network.
|
||||
* [WHiSSPR- Human transparency over identity and surveillance risk](https://iiw.idcommons.net/23E/_WHiSSPR-_Human_transparency_over_identity_and_surveillance_risk) by Sal D’Agostino
|
||||
* [Building ActivityPub into Known](https://werd.io/2021/building-activitypub-into-known) Ben Werdmüller
|
||||
|
||||
* [Known](https://withknown.com/) has supported [Indieweb](https://indieweb.org/) standards since the beginning, but Fediverse has been notably missing. I think that’s a big omission, but also not something I’ve had bandwidth to fix.
|
||||
|
||||
* [ActivityPub support · Issue #2615 · idno/known · GitHub](https://github.com/idno/known/issues/2615%23issuecomment-991335313)
|
||||
|
||||
This issue now has a funding of 3004.5068 USD (3000.0 USD @ $1.0/USD) attached to it.
|
||||
|
||||
- If you would like to work on this issue you can 'start work' [on the Gitcoin Issue Details page](https://gitcoin.co/issue/idno/known/2615/100027300).
|
||||
- Want to chip in? Add your own contribution [here](https://gitcoin.co/issue/idno/known/2615/100027300).
|
||||
- Questions? Checkout [Gitcoin Help](https://gitcoin.co/help) or the [Gitcoin's Discord](https://discord.gg/gitcoin/)
|
||||
- $5,664,407.63 more funded OSS Work available on the [Gitcoin Issue Explorer](https://gitcoin.co/explorer)
|
||||
|
||||
|
||||
* [Implement Client Credentials with Kong Konnect and Okta](https://developer.okta.com/blog/2021/05/25/client-credentials-kong-konnect)
|
||||
> The OIDC plugin enables Kong, as the API gateway, to communicate with Okta via the OAuth/OIDC flows.
|
||||
|
||||
* [ION – We Have Liftoff!](https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-we-have-liftoff/ba-p/1441555)
|
||||
> We are excited to share that v1 of [ION](https://identity.foundation/ion/) is complete and has been launched on Bitcoin mainnet. We have deployed an ION node to our production infrastructure and are working together with other companies and organizations to do so as well. ION does not rely on centralized entities, trusted validators, or special protocol tokens – ION answers to no one but you, the community. Because ION is an open, permissionless system, anyone can run an ION node, in fact the more nodes in operation, the stronger the network becomes. Development of ION, and the Sidetree standard ION is based on, takes place in the [Decentralized Identity Foundation](https://identity.foundation/) (DIF). Read on to learn how you can integrate ION, DIDs, and Verifiable Credentials in your applications and services.
|
||||
|
||||
* [Sidetree Protocol reaches V1](https://blog.identity.foundation/sidetree-protocol-reaches-v1/) DIF
|
||||
> This week, the DIF Steering Committee officially approved the first major release of the Sidetree Protocol specification, "v1" so to speak. This protocol has already been implemented, and four of its implementers have been collaborating intensively for over a year on expanding and extending this specification together.
|
||||
|
||||
* [PROPOSAL: Confidential Storage Specification Refactoring 0.2 – March 24, 2021](https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0245.html)
|
||||
> Based on the March 11 Zoom discussion where we worked hard to discern the differences between Agents, Hubs, and EDVs (and I believe were largely successful IMO), I’ve like to propose to the SDS/CS WG that we refactor the current Confidential Storage specification into 3 separable parts/specifications.
|
||||
|
||||
## Identity Not SSI
|
||||
|
||||
|
||||
|
||||
|
||||
* [A Universal Resolver for self-sovereign identifiers](https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c)
|
||||
* [On any blockchain or other decentralized system](https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c) (Markus Sabadello)
|
||||
> This is a first step in fulfilling DIF’s mission to help individuals and organizations to control their digital identity, without being dependent on any intermediary party.
|
||||
>
|
||||
> This tool fulfills a similar purpose as Bind does in the DNS system: resolution of identifiers. However, instead of working with domain names, we work with self-sovereign identifiers that can be created and registered directly by the entities they refer to.
|
||||
|
||||
## Established Tech
|
||||
|
||||
|
||||
* [ION reaches 1.0](https://github.com/decentralized-identity/ion)
|
||||
> ION makes it possible to anchor tens of thousands of DID/DPKI operations on a target chain (in ION's case, Bitcoin) using a single on-chain transaction. The transactions are encoded with a hash that ION nodes use to fetch, store, and replicate the hash-associated DID operation batches via IPFS.
|
||||
@ -5,75 +5,116 @@ 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.
|
||||
|
||||
|
||||
## In general
|
||||
* [FYI: What makes a standard ‘world class’?](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0213.html) Michael Herman (Trusted Digital Web) (Saturday, 14 August)
|
||||
> - A world class standard should have well-defined objectives that respond to real needs in a timely manner.
|
||||
> - Its technical content should be complete and accurate.
|
||||
> - It should be easy to understand (or as easy as the subject matter allows!) and easy to implement.
|
||||
> - Its requirements should be expressed clearly and unambiguously.
|
||||
> - It should be validated.
|
||||
> - It should be well-maintained.
|
||||
>
|
||||
> Reference: [A Guide To Writing World Class Standards](https://www.etsi.org/images/files/Brochures/AGuideToWritingWorldClassStandards.pdf)
|
||||
* [Trust Frameworks? Standards Matter](https://medium.com/@trbouma/trust-frameworks-standards-matter-47c946992f44) Tim Bouma
|
||||
> He points at the NIST documents about it [Developing Trust Frameworks to Support Identity Federations](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8149.pdf) published in 2018. He also points at the Canadian government’s definition of standards.
|
||||
>
|
||||
> “a document that provides a set of agreed-upon rules, guidelines or characteristics for activities or their results. Standards establish accepted practices, technical requirements, and terminologies for diverse fields.” He goes on to highlight a lot of the work being done in Canada and where it all sits relative to being a standard - “In closing, there are lots of trust frameworks being developed today. But to be truly trusted, a trust framework needs to either apply existing standards or become a standard itself.”
|
||||
* [Open standards should be developed openly](https://blog.weareopen.coop/open-standards-should-be-developed-openly-1f0cf552308d) WeAreOpen
|
||||
> Open standards should be developed openly because not enough people work to ensure that equity is central to innovation and development. We believe that openness is an attitude, and one which bears fruit over time from which everyone can benefit.
|
||||
|
||||
* A world class standard should have well-defined objectives that respond to real needs in a timely manner.
|
||||
* [Global Standards Mapping Initiative](https://www.continuumloop.com/global-standards-mapping-initiative/) ContinuumLoop
|
||||
|
||||
* Its technical content should be complete and accurate.
|
||||
This past November, the GBBC released [The Global Standards Mapping Initiative 2.0](https://gbbcouncil.org/wp-content/uploads/2021/11/GBBC-GSMI-2.0-Report-1.pdf), updating the [standards published in 2020](https://gbbcouncil.org/wp-content/uploads/2020/10/GSMI-Legal-Regulatory-Report.pdf). The GBBC is a strong proponent of standardization and intends to serve as a baseline for establishing frameworks and standards that will allow for adoption and innovation.
|
||||
* [Premature Standardization & Interoperability](https://www.continuumloop.com/premature-standardization-interoperability/) Continuum Loop
|
||||
|
||||
* It should be easy to understand (or as easy as the subject matter allows!) and easy to implement.
|
||||
Here’s my premise – we don’t have standards nor interoperability – at least not as people really need. We have been through a process that is powerful and good – but what we have is what I call “premature standardization.” It’s a great start but nowhere near where things will be.
|
||||
|
||||
* Its requirements should be expressed clearly and unambiguously.
|
||||
* [Trinsic Basics: What Are SSI Standards?](https://trinsic.id/what-are-ssi-standards/)
|
||||
> There are two kinds of standards that Trinsic implements to enable interoperability and avoid vendor lock-in: data model standards and protocol standards.
|
||||
|
||||
* It should be validated.
|
||||
* [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.
|
||||
|
||||
* It should be well-maintained.
|
||||
|
||||
Reference: [A Guide To Writing World Class Standards](https://www.etsi.org/images/files/Brochures/AGuideToWritingWorldClassStandards.pdf)
|
||||
## 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)\
|
||||
|
||||
In the 17 years i worked at W3C, the formal objections were
|
||||
## New
|
||||
|
||||
(1) "we [the objector] wanted to be on record as saying this but go ahead and publish" (the most common);
|
||||
* [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.
|
||||
|
||||
(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)
|
||||
|
||||
* [We're not the only community with problems (Fwd: Open Letter to Debian election candidates about Debian vendettas)](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0127.html) Manu Sporny (Saturday, 19 March)
|
||||
|
||||
Just a reminder that these "politics" and "other-ing" isn't some weird by product of the "identity community", or DIF, or CCG, or OpenID... it's endemic in any long-lived community composed of human beings.
|
||||
|
||||
It's not something you're ever rid of... it's something you manage over time;
|
||||
## 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/)
|
||||
|
||||
> - [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.
|
||||
[CCG Highlights](https://lists.w3.org/Archives/Public/public-credentials/)
|
||||
|
||||
* [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.
|
||||
|
||||
> 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)
|
||||
> Green - General data format standards
|
||||
> Yellow - Vocabulary standards (I the mislabeled VC work)
|
||||
> Magenta - Protocol standards (I mislabeled DID Resolution)
|
||||
> 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)
|
||||
|
||||
Green - General data format standards
|
||||
|
||||
Yellow - Vocabulary standards (I the mislabeled VC work)
|
||||
|
||||
Magenta - Protocol standards (I mislabeled DID Resolution)
|
||||
|
||||
Red - Low-level cryptographic primitives
|
||||
|
||||
Purple - General crypto packaging/protocol standards
|
||||
|
||||
Orange - Application layer standards
|
||||
|
||||
### Verifier Universal Interface
|
||||
* [Verifier Universal Interface by Gataca España S.L.](https://essif-lab.eu/verifier-universal-interface-by-gataca-espana-s-l/)
|
||||
> This draft version can be found at [https://gataca-io.github.io/verifier-apis/](https://gataca-io.github.io/verifier-apis/) and has been built using ReSpec.
|
||||
> This draft version for VUI includes today 6 APIs:
|
||||
@ -86,160 +127,99 @@ Orange - Application layer standards
|
||||
> - Credential status resolution
|
||||
|
||||
|
||||
* [Trust Frameworks? Standards Matter](https://medium.com/@trbouma/trust-frameworks-standards-matter-47c946992f44) Tim Bouma
|
||||
> He points at the NIST documents about it [Developing Trust Frameworks to Support Identity Federations](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8149.pdf) published in 2018. He also points at the Canadian government’s definition of standards.
|
||||
>
|
||||
> “a document that provides a set of agreed-upon rules, guidelines or characteristics for activities or their results. Standards establish accepted practices, technical requirements, and terminologies for diverse fields.” He goes on to highlight a lot of the work being done in Canada and where it all sits relative to being a standard - “In closing, there are lots of trust frameworks being developed today. But to be truly trusted, a trust framework needs to either apply existing standards or become a standard itself.”
|
||||
|
||||
### WebAuthn
|
||||
|
||||
* [W3C WebAuthn V2 Now a Standard](https://self-issued.info/?p%3D2160) Mike Jones
|
||||
> While remaining compatible with the original standard, this second version adds additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format. ([Recommendation](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/)) ([CTAP also approaching standardization](https://self-issued.info/?p%3D2155).
|
||||
* [Federated Identity, InCommon, and Enabling Federated Access to Research Services](https://njedge.net/blog/federated-identity-incommon-and-enabling-federated-access-to-research-services/)
|
||||
> The panel will review the concepts of federated identities, authentication, and the role attributes play in managing access to services. They’ll further describe how the InCommon Federation and eduGAIN enable academic collaboration across local, regional, national, and international scales, discuss technical alternatives for participation in InCommon, and delve a bit into how research communities and research cyberinfrastructures manage federated access to their services.
|
||||
* [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)
|
||||
* [Web Authentication: An API for accessing Public Key Credentials Level 2](https://www.w3.org/TR/2021/PR-webauthn-2-20210225/). This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.
|
||||
* [Second Version of W3C Web Authentication (WebAuthn) advances to Proposed Recommendation (PR)](https://self-issued.info/?p%3D2149)
|
||||
> The World Wide Web Consortium (W3C) has published this [Proposed Recommendation (PR)](https://www.w3.org/TR/2021/PR-webauthn-2-20210225/) Level 2 specification, bringing the second version of WebAuthn one step closer to becoming a completed standard. While remaining compatible with the original standard, this second version adds additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format.
|
||||
* [Near-Final Second W3C WebAuthn and FIDO2 CTAP Specifications](https://self-issued.info/?p=2143)
|
||||
> The [W3C WebAuthn](https://www.w3.org/blog/webauthn/) and [FIDO2](https://fidoalliance.org/fido2/) working groups have been busy this year preparing to finish second versions of the W3C Web Authentication (WebAuthn) and FIDO2 Client to Authenticator Protocol (CTAP) specifications
|
||||
|
||||
### KMIP
|
||||
|
||||
* [OASIS releases KMIP 2.1](https://www.oasis-open.org/2020/12/18/key-management-interoperability-protocol-specification-and-key-management-interoperability-protocol-profiles-oasis-standards-published/)
|
||||
> The Key Management Interoperability Protocol (KMIP) is a single, comprehensive protocol for communication between clients that request any of a wide range of encryption keys and servers that store and manage those keys. By replacing redundant, incompatible key management protocols, KMIP provides better data security while at the same time reducing expenditures on multiple products.
|
||||
|
||||
### OMG
|
||||
* [OMG ISSUES RFI FOR DISPOSABLE SELF-SOVEREIGN IDENTITY STANDARD](https://www.omg.org/news/releases/pr2021/01-21-21.htm)
|
||||
> This RFI aims to gain a better understanding of the self-sovereign identity space. In particular, the Blockchain PSIG is exploring the potential for standards setting in the area of contextually constrained or ‘disposable’ self-sovereign identity arrangements, building on top of existing W3C standards for self-sovereign identity [DID] and verifiable credentials [VC]. The aim of this RFI is to determine whether new standards for this specific aspect of self-sovereign identity are necessary, desirable and timely, and are not already being developed elsewhere. (The RFI)
|
||||
|
||||
A [public presentation on the Disposable Self-sovereign Identity RFI](https://www.brighttalk.com/webcast/12231/461001) will be held on February 3, 2021 at 11:00 AM ET.
|
||||
> The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium, founded in 1989. OMG standards are driven by vendors, end-users, academic institutions and government agencies. OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries.
|
||||
* [Web Authentication: An API for accessing Public Key Credentials Level 2](https://www.w3.org/TR/2021/PR-webauthn-2-20210225/). This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.
|
||||
* [Second Version of W3C Web Authentication (WebAuthn) advances to Proposed Recommendation (PR)](https://self-issued.info/?p%3D2149)
|
||||
> The World Wide Web Consortium (W3C) has published this [Proposed Recommendation (PR)](https://www.w3.org/TR/2021/PR-webauthn-2-20210225/) Level 2 specification, bringing the second version of WebAuthn one step closer to becoming a completed standard. While remaining compatible with the original standard, this second version adds additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format.
|
||||
## Identity not SSI
|
||||
|
||||
* [Near-Final Second W3C WebAuthn and FIDO2 CTAP Specifications](https://self-issued.info/?p=2143)
|
||||
|
||||
The [W3C WebAuthn](https://www.w3.org/blog/webauthn/) and [FIDO2](https://fidoalliance.org/fido2/) working groups have been busy this year preparing to finish second versions of the W3C Web Authentication (WebAuthn) and FIDO2 Client to Authenticator Protocol (CTAP) specifications
|
||||
* [Announcing Schema Markup Validator: validator.schema.org (beta)](http://blog.schema.org/2021/05/announcing-schema-markup-validator.html)
|
||||
|
||||
SDTT is a tool from Google which began life as the [Rich Snippets Testing Tool](https://developers.google.com/search/blog/2010/09/rich-snippets-testing-tool-improvements) back in 2010. Last year Google [announced plans](https://developers.google.com/search/blog/2020/07/rich-results-test-out-of-beta) to migrate from SDTT to successor tooling, the [Rich Results Test](https://search.google.com/test/rich-results), alongside plans to "deprecate the Structured Data Testing Tool". The newer Google tooling is focused on helping publishers who are targeting specific schema.org-powered [searc](https://developers.google.com/search/docs/guides/search-gallery)[h features](https://www.blogger.com/) offered by Google, and for these purposes is a huge improvement as it contextualizes many warnings and errors to a specific target application.
|
||||
|
||||
## Standards
|
||||
|
||||
* [Decentralized Identity FAQ](https://identity.foundation/faq/%23agent-frameworks-infrastructure-layer-2)
|
||||
|
||||
DIF
|
||||
|
||||
* [Bloom donates WACI](https://medium.com/decentralized-identity/bloom-donates-waci-790f902ac9bd)
|
||||
|
||||
At its core, WACI can be thought of as a handshake using classic, industry-standard [JWT](https://datatracker.ietf.org/doc/html/rfc7519)s: the “Relying Party” signs a token given to the end-user’s wallet, and the wallet signs over a “challenge” contained within it, proving ownership of a DID.
|
||||
|
||||
* [The Verifiable Economy: Fully Decentralized Object (FDO) Example: Bob’s UDID Document](https://hyperonomy.com/2021/06/15/the-verifiable-economy-fully-decentralized-object-fdo-example-bobs-udid-document/)
|
||||
|
||||
Strongly-typed Code to Generate Bob’s UDID Document
|
||||
|
||||
|
||||
## Agents
|
||||
|
||||
* [Agent Frameworks & Infrastructure (“Layer 2”)](https://identity.foundation/faq/#agent-frameworks-infrastructure-layer-2)
|
||||
|
||||
* [Mobile Agent Development FAQ](https://iiw.idcommons.net/1L/_Mobile_Agent_Development_FAQ) by Horacio Nunez
|
||||
> - What’s the best place to start creating your own mobile agent?
|
||||
> - How do you get updates once you ship your first version?
|
||||
> - Do I actually have to support a fork for every mobile agent I create?
|
||||
> - Do I need to use a Mediator?
|
||||
|
||||
|
||||
## Schema.org
|
||||
|
||||
* [Schema.org is ten!](http://blog.schema.org/2021/06/schemaorg-is-ten.html)
|
||||
|
||||
Schema.org was founded on the idea of making it easier and simpler for the ordinary, everyday sites that make up the web to use machine-readable data, and for that data to enable an ecosystem of applications used by millions of people. While it's hard to predict exactly what the next decade will bring, if we can all keep these founding concerns in mind as we improve, refine and curate our growing collection of schemas, we'll be doing our part to continue improving the web.
|
||||
|
||||
## Identiverse
|
||||
* [Reflections from Identiverse: Identity Security Threats & Trends](https://www.secureauth.com/blog/reflections-from-identiverse-identity-security-threats-and-trends/) SecureAuth
|
||||
> talks like [“Simplify Your Least-Privilege Journey with Access Analysis”](https://identiverse.com/idv2021/session/SESCI5F77RW8COIGZ/) and [“Managing and governing workload identities”](https://identiverse.com/idv2021/session/SESTZ5WNB1OMKD9EV/) definitively provide greater insight. [...] UberEther showed in [“User Behavior Analytics: Marrying Identity and the SOC Like Peanut Butter and Jelly”](https://pheedloop.com/identiverse2021/virtual/?page%3Dsessions%26section%3DSESKWZML7NBJX42P3) how UBA (User Behavior Analytics) and UEBA (User Events Behavior Analysis) deliver additional value to help avoid threats in real-time and provide visibility to analysts.
|
||||
|
||||
talks like [“Simplify Your Least-Privilege Journey with Access Analysis”](https://identiverse.com/idv2021/session/SESCI5F77RW8COIGZ/) and [“Managing and governing workload identities”](https://identiverse.com/idv2021/session/SESTZ5WNB1OMKD9EV/) definitively provide greater insight. [...] UberEther showed in [“User Behavior Analytics: Marrying Identity and the SOC Like Peanut Butter and Jelly”](https://pheedloop.com/identiverse2021/virtual/?page%3Dsessions%26section%3DSESKWZML7NBJX42P3) how UBA (User Behavior Analytics) and UEBA (User Events Behavior Analysis) deliver additional value to help avoid threats in real-time and provide visibility to analysts.
|
||||
|
||||
* [Kaliya Young on Identikit with Michelle Dennedy](https://identitywoman.net/podcast-identikit-with-michelle-dennedy/)
|
||||
|
||||
our latest series examining the evolution of digital identity, and how self-sovereign identity, specifically, can advance a consent-based economy.
|
||||
## Oasis
|
||||
* [Managed Open Projects: A New Way For Open Source and Open Standards To Collaborate](https://www.oasis-open.org/2021/09/08/managed-open-projects/)
|
||||
|
||||
I recently pointed out in a [TechCrunch contribution](https://techcrunch.com/2021/06/09/a-revival-at-the-intersection-of-open-source-and-open-standards/) that the open source and open standards communities need to find ways to team up if they are to continue driving innovation and development of transformative technologies to push our society forward.
|
||||
|
||||
## JSON
|
||||
|
||||
* [JSON is Robot Barf](https://www.windley.com/archives/2021/09/json_is_robot_barf.shtml) Windley
|
||||
|
||||
JSON has its place. But I think we're overusing it in places where a good notation would serve us better.
|
||||
|
||||
## DIF
|
||||
* [Q&A: The Potential of Decentralized ID in Travel](https://www.webintravel.com/qa-the-potential-of-decentralized-digital-id-in-travel/) WebInTravel
|
||||
> Since February he has also been the informal chair of the [Hospitality and Travel Special Interest Group](https://www.notion.so/dif/HOSPITALITY-TRAVEL-SIG-242105321e1747f8bce776bf634a55b3), a subset within the Decentralized Identity Foundation, an organization creating technical specifications and reference implementations for decentralized identity and working with industries for commercial applications of such technologies.
|
||||
* [Bloom donates WACI](https://medium.com/decentralized-identity/bloom-donates-waci-790f902ac9bd)
|
||||
|
||||
Since February he has also been the informal chair of the [Hospitality and Travel Special Interest Group](https://www.notion.so/dif/HOSPITALITY-TRAVEL-SIG-242105321e1747f8bce776bf634a55b3), a subset within the Decentralized Identity Foundation, an organization creating technical specifications and reference implementations for decentralized identity and working with industries for commercial applications of such technologies.
|
||||
At its core, WACI can be thought of as a handshake using classic, industry-standard [JWT](https://datatracker.ietf.org/doc/html/rfc7519)s: the “Relying Party” signs a token given to the end-user’s wallet, and the wallet signs over a “challenge” contained within it, proving ownership of a DID.
|
||||
|
||||
* [DIF Monthly #28](https://blog.identity.foundation/dif-monthly-28/)
|
||||
|
||||
Table of contents: 1. [Foundation News](https://blog.identity.foundation/dif-monthly-28/%23foundation); 2. [Group Updates](https://blog.identity.foundation/dif-monthly-28/%23groups); 3. [Member Updates](https://blog.identity.foundation/dif-monthly-28/%23members); 4. [Digital Identity Community](https://blog.identity.foundation/dif-monthly-28/%23Community); .5. [Funding](https://blog.identity.foundation/dif-monthly-28/%23funding); 6. [Events](https://blog.identity.foundation/dif-monthly-28/%23community); 7. [Hackathons](https://blog.identity.foundation/dif-monthly-28/%23hackathons); 8. [Jobs](https://blog.identity.foundation/dif-monthly-28/%23jobs); 9. [Metrics](https://blog.identity.foundation/dif-monthly-28/%23metrics); 10. [Get involved! Join DIF](https://blog.identity.foundation/dif-monthly-28/%23join)
|
||||
|
||||
## Spruce
|
||||
* [Sign in with Ethereum](https://login.xyz/) is being developed by Spruce
|
||||
|
||||
Already used throughout web3, this is an effort to standardize the method with best practices and to make it easier for web2 services to adopt it.
|
||||
|
||||
|
||||
## ISO 27001
|
||||
* [WAYF certificeret efter ISO 27001](https://www.wayf.dk/en/node/317)
|
||||
|
||||
WAYF has now been certified according to the standard for information security ISO 27001. This is the result of the audit that DNV conducted at WAYF on 23 September 2021. Language Danish Read more about WAYF certified according to ISO 27001
|
||||
* [What Is ISO 27001:2013? A Guide for Businesses](https://auth0.com/blog/what-is-iso-27001-2013-a-guide-for-businesses/)
|
||||
> ISO 27001 is also the cornerstone of a growing international consensus about data security best practices. Australia based its federal Digital Security Policy on ISO 27001. Likewise, ISO 27001 can provide guidance on how to meet the standards of other data privacy laws, such as the GDPR, which often direct companies to it as an example of universal best practices. So if you abide by ISO 27001’s recommendations, you’re on the right track for legal compliance, not to mention improved data security.
|
||||
|
||||
|
||||
* [How Yoma Uses Trinsic to Help African Youth Build Digital CVs](https://trinsic.id/customer-story-yoma/)
|
||||
|
||||
Verifiable credentials is a beautiful set of technology that allows people and organizations to get the data in a verifiable form that still respects agency.”
|
||||
|
||||
Lohan Spies, Technical Lead, Yoma
|
||||
|
||||
* [Explore Affinidi Schema Manager](https://ui.schema.affinidi.com/schemas/)
|
||||
|
||||
* [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.
|
||||
|
||||
|
||||
## OpenBadges
|
||||
|
||||
* [Keep Badges Weird…](https://blog.weareopen.coop/keep-badges-weird-e26a1b055ff5) at the Badge Summit
|
||||
|
||||
We have a new suite of badges to encourage participation, create value for others, and reflect on that experience. Participants will be able to both earn AND award badges, so they’ll have a chance to prove that they’ve understood the theory surrounding CoPs and badges as well as put those theories into practice.
|
||||
* [Mission Accomplished: Universal Resolver Calls coming to an end](https://blog.identity.foundation/universal-resolver-calls-wrapup/) Identity Foundation
|
||||
|
||||
Considering that the group has accomplished these goals, there is currently no more need for dedicated calls. Work on the Universal Resolver work item will continue on Github (under the [Universal Resolver](https://github.com/decentralized-identity/universal-resolver) and [Identifiers &Discovery](https://github.com/decentralized-identity/identifiers-discovery/) and on DIF Slack in the Identifiers & Discovery Working Group channel, #wg-id.
|
||||
|
||||
> We have a new suite of badges to encourage participation, create value for others, and reflect on that experience. Participants will be able to both earn AND award badges, so they’ll have a chance to prove that they’ve understood the theory surrounding CoPs and badges as well as put those theories into practice.
|
||||
* [Discover Open Badges 3.0!](https://app.participate.com/communities/keep-badges-weird/62003f3f-a7ba-4f6a-990a-64d6f893016d/announcements/0bc15852-0f91-48c8-a7ca-478b246b553c) Keep Badges Weird
|
||||
|
||||
1. Check out the (accepted) [Open Badges 3.0 proposal](https://github.com/IMSGlobal/openbadges-specification/files/6977048/Proposal-Open-Badges-3.0-update-08-11-2021.pdf)
|
||||
2. [Watch a video](https://www.youtube.com/watch?v%3DQDGPwR1F3FY%26t%3D1357s) from the ePIC conference giving an overview of what Open Badges 3.0 will enable (or view the [slide deck](https://docs.google.com/presentation/d/1NEJoQaI9b6KC1EFDDhR3MGybGVoa0R3bQh0xuKtUKkY)
|
||||
3. Discuss what this means for you, your organisation, or your community in [this thread](https://app.participate.com/discussions/open-badges-3-0/68917656-db8f-4932-88fd-153fdb54e285)
|
||||
|
||||
|
||||
> 1. Check out the (accepted) [Open Badges 3.0 proposal](https://github.com/IMSGlobal/openbadges-specification/files/6977048/Proposal-Open-Badges-3.0-update-08-11-2021.pdf)
|
||||
> 2. [Watch a video](https://www.youtube.com/watch?v%3DQDGPwR1F3FY%26t%3D1357s) from the ePIC conference giving an overview of what Open Badges 3.0 will enable (or view the [slide deck](https://docs.google.com/presentation/d/1NEJoQaI9b6KC1EFDDhR3MGybGVoa0R3bQh0xuKtUKkY)
|
||||
> 3. Discuss what this means for you, your organisation, or your community in [this thread](https://app.participate.com/discussions/open-badges-3-0/68917656-db8f-4932-88fd-153fdb54e285)
|
||||
* [Reflecting on the Evolving Badges and Credentials Ecosystem](https://blog.weareopen.coop/reflecting-on-the-evolving-badges-and-credentials-ecosystem-6efac4d673d3)
|
||||
> Recently, the WAO team took the opportunity to update the badge platforms page on Badge Wiki, a knowledgebase for the Open Badge community. As the ecosystem continues to evolve we’re seeing some early platforms fall by the wayside and new platforms emerge.
|
||||
* [What is Open Recognition, anyway?](https://blog.weareopen.coop/what-is-open-recognition-anyway-9f38ec1f8629) Going beyond credentialing and the formal/informal divide
|
||||
|
||||
Recently, the WAO team took the opportunity to update the badge platforms page on Badge Wiki, a knowledgebase for the Open Badge community. As the ecosystem continues to evolve we’re seeing some early platforms fall by the wayside and new platforms emerge.
|
||||
Badges as credentials includes approaches that are well understood and largely replace or augment existing certification practices. Badges for recognition, however, include approaches that remain somewhat confusing to many people.
|
||||
|
||||
|
||||
|
||||
|
||||
* [Report from EBSI4Austria. In 2018, all European member states…](https://medium.com/@markus.sabadello/report-from-ebsi4austria-b79c0ed8ab8d) Markus Sabadello
|
||||
|
||||
EBSI4Austria is a CEF funded project with two main objectives. First, EBSI4Austria aims to set up, operate and maintain the Austrian’s EBSI node. Second, we pilot the diploma use case on the Austrian level supported by two Universities and data providers as well as verifiers.
|
||||
|
||||
## Blockcerts
|
||||
* [Blockcerts V3 release](https://community.blockcerts.org/t/blockcerts-v3-release/3022)
|
||||
|
||||
The main change is the alignment with the [W3C Verifiable Credentials specification 3](https://www.w3.org/TR/vc-data-model/).
|
||||
@ -248,7 +228,7 @@ Regarding the standard itself metadata and display are entering the default stan
|
||||
|
||||
display brings in [a little bit of novelty 2](https://github.com/blockchain-certificates/cert-schema/blob/master/cert_schema/3.0/displaySchema.json%23L6) images or pdfs, in addition to the more classic HTML.
|
||||
|
||||
|
||||
### XSL SDI
|
||||
|
||||
* [XSL Labs: Your Data Belongs to You](https://www.xsl-labs.io/whitepaper/white_paper_en.pdf)
|
||||
|
||||
@ -256,44 +236,15 @@ The SDI technology constitutes a very important example of decentralized counter
|
||||
|
||||
|
||||
|
||||
|
||||
* [Self-Sovereign Identity (SSI) and Verifiable Credentials (VC) in Ocean Protocol](https://port.oceanprotocol.com/t/proposal-walt-id-bringing-self-sovereign-identity-ssi-and-verifiable-credentials-vc-to-ocean-protocol-proof-of-concept/976)
|
||||
|
||||
What already exists, more recently: [fine-grained permissions 1](https://blog.oceanprotocol.com/fine-grained-permissions-now-supported-in-ocean-protocol-4fe434af24b9):
|
||||
|
||||
1. Marketplace-level fine-grained permissions for browsing, publishing, etc within a marketplace frontend
|
||||
2. Asset-level fine-grained permissions on consuming the asset itself
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* [NFTs, Verifiable Credentials, and Picos](https://www.windley.com/archives/2021/10/nfts_verifiable_credentials_and_picos.shtml) Phil Windley
|
||||
|
||||
Summary: The hype over NFTs and collectibles is blinding us to their true usefulness as trustworthy persistent data objects. How do they sit in the landscape with verifiable credentials and picos? Listening to this Reality 2.0 podcast about NFTs with Doc Searls, Katherine Druckman, and their guest Greg Bledsoe got me thinking about NFTs.
|
||||
|
||||
|
||||
|
||||
* [Open standards should be developed openly](https://blog.weareopen.coop/open-standards-should-be-developed-openly-1f0cf552308d)
|
||||
|
||||
Open standards should be developed openly because not enough people work to ensure that equity is central to innovation and development. We believe that openness is an attitude, and one which bears fruit over time from which everyone can benefit.
|
||||
|
||||
### CCI
|
||||
* [Use Case Implementation Workstream](https://covidcreds.groups.io/g/usecaseCCI) [usecaseCCI@covidcreds.groups.io](mailto:usecaseCCI@covidcreds.groups.io)
|
||||
|
||||
This is the Use Case Implementation Workstream of the [COVID Credentials Initiative (CCI)](https://www.covidcreds.com/). This workstream identifies privacy-preserving verifiable credentials (VCs) that are most useful to the COVID-19 response and provides a forum and platform for those who are implementing COVID VCs to present their projects/solutions.
|
||||
|
||||
### VON\ION
|
||||
* [@csuwildcat](https://twitter.com/csuwildcat) shares
|
||||
> As of Friday, we believe v1 of ION is functionally code complete, and the Sidetree Working Group at DIF (@DecentralizedID) should have a v1 spec candidate ready for the underlying protocol by Jan 21st. Public v1 launch of the ION network on Bitcoin mainnet is just weeks away.
|
||||
|
||||
* [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.
|
||||
|
||||
* [What Is ISO 27001:2013? A Guide for Businesses](https://auth0.com/blog/what-is-iso-27001-2013-a-guide-for-businesses/)
|
||||
> ISO 27001 is also the cornerstone of a growing international consensus about data security best practices. Australia based its federal Digital Security Policy on ISO 27001. Likewise, ISO 27001 can provide guidance on how to meet the standards of other data privacy laws, such as the GDPR, which often direct companies to it as an example of universal best practices. So if you abide by ISO 27001’s recommendations, you’re on the right track for legal compliance, not to mention improved data security.
|
||||
|
||||
### 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)
|
||||
|
||||
@ -301,21 +252,13 @@ W3C Data Privacy Vocabulary Control
|
||||
|
||||
* [https://dpvcg.github.io/dpv/#Representative](https://dpvcg.github.io/dpv/%23Representative)
|
||||
|
||||
* [Mobile Agent Development FAQ](https://iiw.idcommons.net/1L/_Mobile_Agent_Development_FAQ) by Horacio Nunez
|
||||
* [Primer] [Data Privacy Vocabulary (DPV)](https://w3c.github.io/dpv/primer/%23core-taxonomy) w3c
|
||||
|
||||
This session had the objective to gather (and discuss) a set of recurrent questions people experience when trying to build their first mobile agents.
|
||||
Call for Comments/Feedbacks for DPV v1.0 release
|
||||
|
||||
This was the end result of the session:
|
||||
Please provide your comments by 15-OCT-2022 via [GitHub](https://github.com/w3c/dpv/issues/50) or [public-dpvcg@w3.org](https://lists.w3.org/Archives/Public/public-dpvcg/) (mailing list).
|
||||
|
||||
FAQ
|
||||
|
||||
What’s the best place to start creating your own mobile agent?
|
||||
|
||||
How do you get updates once you ship your first version?
|
||||
|
||||
Do I actually have to support a fork for every mobile agent I create?
|
||||
|
||||
Do I need to use a Mediator?
|
||||
## Oberon protocol
|
||||
|
||||
* [Better and more secure methods for API authentication](https://iiw.idcommons.net/1D/_Better_and_more_secure_methods_for_API_authentication) by Michael Lodder
|
||||
|
||||
@ -327,49 +270,34 @@ Goal of the Oberon protocol when building an API:
|
||||
- Privacy preserving
|
||||
- No new crypto, uses BLS signature keys and Pointecheval saunders Construction
|
||||
|
||||
### Timestamping
|
||||
|
||||
* [Trusted Timestamping Part 3: Family of Standards](https://medium.com/finema/trusted-timestamping-part-3-family-of-standards-f0c89a5e97ab) Nunnaphat Songmanee Finema
|
||||
|
||||
Read more about timestamping and its concepts at [Trusted Timestamping Part 1: Scenarios](https://medium.com/finema/trusted-timestamping-part-1-scenarios-9bf4a7cc2364) and [Trusted Timestamping Part 2: Process and Safeguards](https://medium.com/finema/trusted-timestamping-part-2-process-and-safeguards-f75286a0c370).
|
||||
|
||||
Family of standards related to timestamping
|
||||
|
||||
|
||||
* [Global Standards Mapping Initiative](https://www.continuumloop.com/global-standards-mapping-initiative/) ContinuumLoop
|
||||
|
||||
This past November, the GBBC released [The Global Standards Mapping Initiative 2.0](https://gbbcouncil.org/wp-content/uploads/2021/11/GBBC-GSMI-2.0-Report-1.pdf), updating the [standards published in 2020](https://gbbcouncil.org/wp-content/uploads/2020/10/GSMI-Legal-Regulatory-Report.pdf). The GBBC is a strong proponent of standardization and intends to serve as a baseline for establishing frameworks and standards that will allow for adoption and innovation.
|
||||
|
||||
### Verfiable presentation
|
||||
* [Verifiable Presentation Personas: Certifiers, Consolidators, & Submitters](https://medium.com/@Transmute/verifiable-presentation-personas-certifiers-consolidators-submitters-b38a281eb92f) Transmute
|
||||
|
||||
The arrow for “Issue Credentials” is exactly the same as “Send Presentation,” leading us to believe these activities are similar, but how are they similar? We can’t adequately answer these questions by looking at the above picture and the specification doesn’t provide a ton of help either…
|
||||
|
||||
* [What is Open Recognition, anyway?](https://blog.weareopen.coop/what-is-open-recognition-anyway-9f38ec1f8629) Going beyond credentialing and the formal/informal divide
|
||||
|
||||
Badges as credentials includes approaches that are well understood and largely replace or augment existing certification practices. Badges for recognition, however, include approaches that remain somewhat confusing to many people.
|
||||
|
||||
|
||||
|
||||
## GAIN
|
||||
|
||||
- [Nat has a presentation](https://nat.sakimura.org/2021/09/14/announcing-gain/)
|
||||
- There is a [linked in Group](https://www.linkedin.com/groups/12559000/)
|
||||
|
||||
|
||||
|
||||
Harrison Tang, CEO of Spokeo, [is the new co-chair of the CCG](https://twitter.com/TheCEODad/status/1544884282316845057)
|
||||
|
||||
W3C CCG (World Wide Web Consortium’s Credentials Community Group) aims to explore the creation, storage, presentation, verification, and user control of credentials (i.e. a set of claims made about someone, or a person record).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Neighboring Standards
|
||||
|
||||
### QR Code
|
||||
* [Secure QR Code Authentication v1.0 from ESAT TC approved as a Committee Specification](https://www.oasis-open.org/2022/07/12/secure-qr-code-authentication-v1-0-from-esat-tc-approved-as-a-committee-specification/)
|
||||
|
||||
An alternative to passwords that includes QR Codes is described, and typical use cases are described. This document also provides an overview and context for using QR Codes for security purposes.
|
||||
|
||||
## PICO
|
||||
|
||||
* [The Most Inventive Thing I've Done](https://www.windley.com/archives/2022/07/the_most_inventive_thing_ive_done.shtml) Phil Windley
|
||||
|
||||
every pico is serverless and cloud-native, presenting an API that can be fully customized by developers. Because they're persistent, picos support databaseless programming with intuitive data isolation. As an actor-model programming system, different picos can operate concurrently without the need for locks, making them a natural choice for easily building decentralized systems.
|
||||
@ -377,114 +305,49 @@ W3C Press Release - [Decentralized Identifiers (DIDs) v1.0 becomes a W3C Recomme
|
||||
|
||||
For individuals in particular, DIDs can put them back in control of their personal data and consent, and also enable more respectful bi-directional trust relationships where forgery is prevented, privacy is honored, and usability is enhanced.
|
||||
|
||||
|
||||
* [DIF Monthly #28](https://blog.identity.foundation/dif-monthly-28/)
|
||||
|
||||
Table of contents: 1. [Foundation News](https://blog.identity.foundation/dif-monthly-28/%23foundation); 2. [Group Updates](https://blog.identity.foundation/dif-monthly-28/%23groups); 3. [Member Updates](https://blog.identity.foundation/dif-monthly-28/%23members); 4. [Digital Identity Community](https://blog.identity.foundation/dif-monthly-28/%23Community); .5. [Funding](https://blog.identity.foundation/dif-monthly-28/%23funding); 6. [Events](https://blog.identity.foundation/dif-monthly-28/%23community); 7. [Hackathons](https://blog.identity.foundation/dif-monthly-28/%23hackathons); 8. [Jobs](https://blog.identity.foundation/dif-monthly-28/%23jobs); 9. [Metrics](https://blog.identity.foundation/dif-monthly-28/%23metrics); 10. [Get involved! Join DIF](https://blog.identity.foundation/dif-monthly-28/%23join)
|
||||
|
||||
## Verification
|
||||
* [Verification Patterns, Part 1](https://docs.centre.io/blog/verification-patterns-1) Verite
|
||||
|
||||
Since verification is off-chain (and generally fast/inexpensive, depending on the provider), and since this avoids on-chain storage of potentially correlatable data, this is often the preferred solution.
|
||||
|
||||
|
||||
## JWP
|
||||
|
||||
* [JSON Web Proofs BoF at IETF 114 in Philadelphia](https://self-issued.info/?p%3D2286)
|
||||
|
||||
- [Chair Slides](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-json-web-proofs-chair-drafts-00) – [Karen O’Donoghue](https://twitter.com/kodonog) and [John Bradley](https://twitter.com/ve7jtb)
|
||||
- [The need: Standards for selective disclosure and zero-knowledge proofs](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-the-need-standards-for-selective-disclosure-and-zero-knowledge-proofs-00) – [Mike Jones](https://twitter.com/selfissued)
|
||||
- [What Would JOSE Do? Why re-form the JOSE working group to meet the need?](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-the-need-standards-for-selective-disclosure-and-zero-knowledge-proofs-00) – [Mike Jones](https://twitter.com/selfissued)
|
||||
|
||||
|
||||
- [A Look Under the Covers: The JSON Web Proofs specifications](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-json-web-proofs-initial-drafts-00) – Jeremie Miller
|
||||
|
||||
|
||||
|
||||
* [Volleyball, Identiverse, and Open Identity Standards](https://www.linkedin.com/pulse/volleyball-identiverse-open-identity-standards-alex-simons/?trackingId%3DiAokBqe0Qdqrwj5LfAEf3w%253D%253D) Alex Simons
|
||||
|
||||
|
||||
|
||||
|
||||
* [Trinsic Builds Open Source Trust Registry Sponsored by eSSIF-Lab](https://trinsic.id/trinsic-builds-open-source-trust-registry-sponsored-by-essif-lab/) Trinsic
|
||||
|
||||
Driven by our motivation to make SSI more adoptable, we built the world’s first turn-key, open source trust registry solution. This work was sponsored by the [European Self-Sovereign Identity Framework Lab](https://essif-lab.eu/), which is an EU consortium that provides funding for projects that build SSI open source tools. Any ecosystem provider can use the trust registry implementation to enable governance in their verifiable data ecosystem.
|
||||
## Trust Registries
|
||||
|
||||
* [Managing Trust and Reputation via Trust Registries](https://www.continuumloop.com/managing-trust-and-reputation-via-trust-registries/) Continuum Loop
|
||||
|
||||
The concept behind a Trust Registry is that a Wallet needs to know which decentralized identifiers (DIDs) to “trust” as a source of truth. At many levels, this “trust” translates to “authority” – knowing that somebody, centralized or decentralized, is responsible for maintaining a list of trusted DIDs.
|
||||
|
||||
* [Dock DIDs Now Support Multiple Key Pairs](https://blog.dock.io/dids-multikey-support/) Dock
|
||||
|
||||
- Keys can be given different capabilities using Verification Relationships
|
||||
- We support 4 Verification Relationships: Authentication, Assertion, Key Agreement, and Capability Invocation.
|
||||
- DIDs can now be controlled by other DIDs
|
||||
- DIDs can now have service endpoints
|
||||
- Dock now supports off-chain DID Documents
|
||||
|
||||
### ONDC
|
||||
* [ONDC: An Open Network for Ecommerce](https://www.windley.com/archives/2022/08/ondc_an_open_network_for_ecommerce.shtml) Phil Windley
|
||||
|
||||
* [Open Network for Digital Commerce](https://en.wikipedia.org/wiki/Open_Network_for_Digital_Commerce) is a non-profit established by the Indian government to develop open ecommerce. The goal is to end platform monopolies in ecommerce using an open protocol called [Beckn](https://developers.becknprotocol.io/). I'd never heard of Beckn before. From the reaction on the VRM mailing list, not many there had either.
|
||||
|
||||
|
||||
## Apple \ Google
|
||||
* [Apple, with support from Google, just announced the Mobile Document Request API](https://github.com/WICG/proposals/issues/67) Web Incubator CG
|
||||
> The API is concerning because it lists "Define the native communication between the User Agent and the application holding the mdoc." as out of scope. That is, digital wallet selection is out of scope. Also out of scope is "issuing" and "provisioning". The specification focuses on delivery from a digital wallet to a website.
|
||||
* [Premature Standardization & Interoperability](https://www.continuumloop.com/premature-standardization-interoperability/) Continuum Loop
|
||||
|
||||
Here’s my premise – we don’t have standards nor interoperability – at least not as people really need. We have been through a process that is powerful and good – but what we have is what I call “premature standardization.” It’s a great start but nowhere near where things will be.
|
||||
|
||||
|
||||
* [IDnow joins Accelerate@IATA to shape the future of seamless air travel](https://www.idnow.io/pr/idnow-joins-accelerateiata/) IDnow
|
||||
|
||||
The goal of IATA One ID is to set industry standards that further streamline the passenger journey with digitalization of admissibility and a contactless process through secure biometric enabled identification.
|
||||
|
||||
Cardano showing interest in our work
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* [Identity Manager – Self Sovereign Identity made Simple](https://tanglelabs.io/identity-manager-self-sovereign-identity-made-simple/) TangleLabs
|
||||
|
||||
By producing an accessible, open-source wrapper library, Tangle Labs provides any business or development team the opportunity to easily explore SSI and to test and prototype solutions that can bring added value to your business.
|
||||
|
||||
* [Introduction to Decentralized Identity](https://wiki.iota.org/identity.rs/decentralized_identity) IOTA Wiki
|
||||
## JWT
|
||||
|
||||
* [Podcast] [Privacy-preserving measures and SD-JWT with Daniel Fett](https://identityunlocked.auth0.com/public/49/Identity%252C-Unlocked.--bed7fada/3bbcbab8) IdentityUnlocked Auth0
|
||||
|
||||
The discussion gets very concrete when Daniel describes selective disclosure JWT, or SD-JWT, a new IETF specification he is coauthoring that offers a simple and easy-to-adopt approach to produce JWTs capable of supporting selective disclosure. Here at Identity, Unlocked, we are huge fans of this new specification, and we hope this episode will help you get started!
|
||||
|
||||
|
||||
Related resources:
|
||||
|
||||
### BBS Creds
|
||||
- [aries-rfcs/0646-bbs-credentials#drawbacks](https://github.com/hyperledger/aries-rfcs/tree/main/features/0646-bbs-credentials%23drawbacks)
|
||||
- [Zero-Knowledge Proofs Do Not Solve the Privacy-Trust Problem of Attribute-Based Credentials: What if Alice Is Evil?](https://ieeexplore.ieee.org/document/9031545) IEEE
|
||||
|
||||
* [Primer] [Data Privacy Vocabulary (DPV)](https://w3c.github.io/dpv/primer/%23core-taxonomy) w3c
|
||||
|
||||
Call for Comments/Feedbacks for DPV v1.0 release
|
||||
|
||||
Please provide your comments by 15-OCT-2022 via [GitHub](https://github.com/w3c/dpv/issues/50) or [public-dpvcg@w3.org](https://lists.w3.org/Archives/Public/public-dpvcg/) (mailing list).
|
||||
|
||||
|
||||
* [Trinsic Basics: What Are SSI Standards?](https://trinsic.id/what-are-ssi-standards/)
|
||||
> There are two kinds of standards that Trinsic implements to enable interoperability and avoid vendor lock-in: data model standards and protocol standards.
|
||||
|
||||
* [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.
|
||||
|
||||
|
||||
|
||||
## Assorted
|
||||
|
||||
|
||||
* [Bootstrapping a VDR-based decentralized object (credential) platform?](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0274.html) Michael Herman (Trusted Digital Web) (Monday, 26 July)
|
||||
|
||||
Here's an [illustration of the relationships between the initial DOMAIN and POOL txns](https://hyperonomy.com/2021/07/26/bootstrapping-a-vdr-based-decentralized-credential-object-platform-von-example/) used to bootstrap an example Aries VDR...
|
||||
|
||||
## C2PA
|
||||
* [FYI: C2PA Releases Specification of World’s First Industry Standard for Content Provenance](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0207.html) Leonard Rosenthol (Wednesday, 26 January)
|
||||
|
||||
Just wanted to update folks here that the C2PA has released version 1.0 of their specification at [https://c2pa.org/specifications/specifications/1.0/index.html](https://c2pa.org/specifications/specifications/1.0/index.html). As previously mentioned, it includes native support for VC’s for use in identification of actors (be they human, organizations, etc.). Thanks to everyone here for their input on our work and helping us to deliver.
|
||||
|
||||
|
||||
* [https://github.com/transmute-industries/xmss](https://github.com/transmute-industries/xmss)
|
||||
|
||||
I've reached the limits of my ability to move this ball forward, and am here to ask for help
|
||||
@ -507,11 +507,6 @@ We’ve been hard at work writing use cases, helping education standards organiz
|
||||
> There was some feedback that BBS, PE, and DIDCommV2 are possible points of convergence.
|
||||
>
|
||||
> Also comments that WACI Bloom may play a part in convergence
|
||||
* [What BBS+ Means For Verifiable Credentials](https://www.youtube.com/watch?v%3DdXlRIrrb9f4) Evernym
|
||||
> In a recent Evernym blog post, [we discussed why BBS+ LD-Proofs](https://www.evernym.com/blog/bbs-verifiable-credentials/) are the privacy-preserving VC format that everyone should implement. In this webinar….
|
||||
> - A brief history of verifiable credential formats, and how a lack of convergence makes scale and interoperability an ongoing challenge
|
||||
> - How BBS+ Signatures are the breakthrough that combine the best of the JSON-LD and ZKP formats, while still allowing for selective disclosure and non-trackability
|
||||
> - The path forward: What remains to be done to fully converge on the BBS+ format
|
||||
|
||||
## Critique
|
||||
|
||||
@ -555,3 +550,6 @@ Subject: RE: One subject, 2 VCs, 2 duplicate properties
|
||||
|
||||
... forking the conversation r.e. Cryptographically Enforceable Issuer Policies @Joosten, H.J.M. (Rieks), how would it be determined if a Verifier satisfies policy conditions? Really interesting idea.
|
||||
|
||||
* [Indexing and Querying Revoked Verifiable Credentials](https://medium.com/51nodes/indexing-and-querying-revoked-verifiable-credentials-e229dc2781d4) 51 Nodes
|
||||
|
||||
this article describes a simple approach to revoke verifiable credentials and a decentralized and efficient way to index and query those revoked credentials using the [Graph protocol](https://thegraph.com/en/).
|
||||
|
||||
@ -4,6 +4,8 @@ published: false
|
||||
|
||||
# Organization
|
||||
|
||||
* [Federated Identity, InCommon, and Enabling Federated Access to Research Services](https://njedge.net/blog/federated-identity-incommon-and-enabling-federated-access-to-research-services/)
|
||||
> The panel will review the concepts of federated identities, authentication, and the role attributes play in managing access to services. They’ll further describe how the InCommon Federation and eduGAIN enable academic collaboration across local, regional, national, and international scales, discuss technical alternatives for participation in InCommon, and delve a bit into how research communities and research cyberinfrastructures manage federated access to their services.
|
||||
|
||||
* [LoginWithFIDO.com](https://loginwithfido.com/)
|
||||
* [Consumer Research](https://fidoalliance.org/consumerresearch/)
|
||||
|
||||
13
_posts/identosphere-dump/organizations/w3c-ccg.md
Normal file
13
_posts/identosphere-dump/organizations/w3c-ccg.md
Normal file
@ -0,0 +1,13 @@
|
||||
# W3C - CCG
|
||||
|
||||
* [We're not the only community with problems (Fwd: Open Letter to Debian election candidates about Debian vendettas)](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0127.html) Manu Sporny (Saturday, 19 March)
|
||||
> Just a reminder that these "politics" and "other-ing" isn't some weird by product of the "identity community", or DIF, or CCG, or OpenID... it's endemic in any long-lived community composed of human beings.
|
||||
>
|
||||
> It's not something you're ever rid of... it's something you manage over time;
|
||||
* [CCG Highlights](https://lists.w3.org/Archives/Public/public-credentials/)
|
||||
|
||||
|
||||
Harrison Tang, CEO of Spokeo, [is the new co-chair of the CCG](https://twitter.com/TheCEODad/status/1544884282316845057)
|
||||
|
||||
W3C CCG (World Wide Web Consortium’s Credentials Community Group) aims to explore the creation, storage, presentation, verification, and user control of credentials (i.e. a set of claims made about someone, or a person record).
|
||||
|
||||
@ -2,6 +2,13 @@
|
||||
published: false
|
||||
---
|
||||
|
||||
|
||||
### EBSI4Austria
|
||||
|
||||
* [Report from EBSI4Austria. In 2018, all European member states…](https://medium.com/@markus.sabadello/report-from-ebsi4austria-b79c0ed8ab8d) Markus Sabadello
|
||||
|
||||
EBSI4Austria is a CEF funded project with two main objectives. First, EBSI4Austria aims to set up, operate and maintain the Austrian’s EBSI node. Second, we pilot the diploma use case on the Austrian level supported by two Universities and data providers as well as verifiers.
|
||||
|
||||
# European Identity
|
||||
|
||||
* [Building interoperable self-sovereign identity for Europe](https://www.youtube.com/watch?v=iN6N_aIeHlU)
|
||||
@ -81,8 +88,8 @@ In episode 40, Roland fills us in on how Verimi works and its privacy-by-design
|
||||
> Timothy Ruff’s analysis and commentary on the EU Announcement this week about its new digital identity strategy.
|
||||
* [EU plans digital ID wallet for bloc’s post-pandemic life](https://apnews.com/article/europe-health-coronavirus-pandemic-lifestyle-travel-73f90d18909c595da463994e16e17348)
|
||||
> The European Digital Identity Wallet proposed by the EU’s executive commission is a smartphone app that would let users store electronic forms of identification and other official documents, such as driver’s licenses, prescriptions and school diplomas.
|
||||
* [EU decision on Identity Wallet: Starting signal for a seamless digital future](https://www.idnow.io/blog/eu-decision-on-identity-wallet-starting-signal-for-a-seamless-digital-future/)
|
||||
> Last week, the EU Commission published a draft for the so-called digital identity wallet “EUid”. According to it, within 12 months of the law coming into force, every EU state must provide its citizens with a digital wallet.
|
||||
|
||||
|
||||
|
||||
* [Where Stands the Sovereign Self?](https://www.kuppingercole.com/blog/hegde/eic-speaker-spotlight-doc-searls-on-decentralized-identity?ref%3Dsmspotlightdoc) Kuppinger Cole
|
||||
|
||||
@ -366,9 +373,7 @@ it is likely that many dApp developers now need an identity solution that preser
|
||||
EU [DATA GOVERNANCE ACT MEETS TOIP FRAMEWORK](https://trustoverip.org/blog/2022/01/13/data-governance-act-meets-toip-framework/) TOIP
|
||||
|
||||
The DGA defines an “intermediary” that facilitates processing and sharing of data for individuals and organizations to “…increase trust in data intermediation services and foster data altruism across the EU”. In the [MyData](https://mydata.org/declaration/) framework for user-controlled data sharing, intermediaries are called [MyData Operators](https://mydata.org/mydata-operators/) and there is a certification program in place.
|
||||
* [How the Digital Markets Act (DMA) will shape the future of digital identity in Europe](https://www.idnow.io/blog/digital-markets-act-dma-future-digital-identity/) IDNow
|
||||
|
||||
On March 24th, 2022, [the European Parliament and Council reached an agreement on the final version of the Digital Markets Act (DMA)](https://eur-lex.europa.eu/legal-content/de/TXT/?qid%3D1608116887159%26uri%3DCOM%253A2020%253A842%253AFIN). According to the European Commission, the DMA regulation is expected to be reviewed and enacted by October 2022.
|
||||
|
||||
* [Overview of Member States' eID strategies](https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/National%2BStrategies)
|
||||
> The report focusses on the approaches towards eID outlined in national strategy documents, together with other supporting documentation and web resources, with the aim of offering a thorough understanding of the eID state of play across Europe.
|
||||
@ -463,3 +468,14 @@ Opportunity 4: Secure messaging.
|
||||
> Europe’s digital transformation of the economy and society is framed by the European strategy for data through the establishment of a common European data space based on domain-specific data spaces in strategic sectors such as environment, agriculture, industry, health and transportation.
|
||||
|
||||
* [Joining forces towards European digital credentials](https://onedrive.live.com/?authkey%3D%2521ADoEGcIwiKDydcg%26cid%3DF7FF746DED29F767%26id%3DF7FF746DED29F767%252183805%26parId%3DF7FF746DED29F767%252183804%26o%3DOneUp) European Commission
|
||||
|
||||
### IDNOW
|
||||
|
||||
* [IDnow joins Accelerate@IATA to shape the future of seamless air travel](https://www.idnow.io/pr/idnow-joins-accelerateiata/) IDnow
|
||||
|
||||
The goal of IATA One ID is to set industry standards that further streamline the passenger journey with digitalization of admissibility and a contactless process through secure biometric enabled identification.
|
||||
* [EU decision on Identity Wallet: Starting signal for a seamless digital future](https://www.idnow.io/blog/eu-decision-on-identity-wallet-starting-signal-for-a-seamless-digital-future/)
|
||||
> Last week, the EU Commission published a draft for the so-called digital identity wallet “EUid”. According to it, within 12 months of the law coming into force, every EU state must provide its citizens with a digital wallet.
|
||||
* [How the Digital Markets Act (DMA) will shape the future of digital identity in Europe](https://www.idnow.io/blog/digital-markets-act-dma-future-digital-identity/) IDNow
|
||||
|
||||
On March 24th, 2022, [the European Parliament and Council reached an agreement on the final version of the Digital Markets Act (DMA)](https://eur-lex.europa.eu/legal-content/de/TXT/?qid%3D1608116887159%26uri%3DCOM%253A2020%253A842%253AFIN). According to the European Commission, the DMA regulation is expected to be reviewed and enacted by October 2022.
|
||||
|
||||
@ -2,6 +2,12 @@
|
||||
|
||||
* [Transforming Scottish Education on the Blockchain](https://digitalscot.net/education-blockchain/) DigitalScot
|
||||
|
||||
https://unece.org/trade/uncefact/guidance-material
|
||||
|
||||
* [The Verifiable Economy: Fully Decentralized Object (FDO) Example: Bob’s UDID Document](https://hyperonomy.com/2021/06/15/the-verifiable-economy-fully-decentralized-object-fdo-example-bobs-udid-document/)
|
||||
|
||||
Strongly-typed Code to Generate Bob’s UDID Document
|
||||
|
||||
A pertinent example of how this can be applied in the corporate world is this example of the [Scottish Social Services Council uses them](https://www.badges.sssc.uk.com/getting-started/what-you-need-to-know-about-open-badges/) to underpin workforce learning. The BCS describes this as the [future of professional development](https://www.bcs.org/content-hub/digital-badging-the-future-of-professional-development/), with many organizations like [Siemens](https://new.siemens.com/uk/en/company/education/teachers/siemens-digital-badges.html) using them this way.
|
||||
* [OWI Digital Forum Recap: The Rise & Adoption of Verifiable Credentials](https://trinsic.id/owi-digital-forum-recap-the-rise-adoption-of-verifiable-credentials/)
|
||||
> Trinsic CEO Riley Hughes sat down with [One World Identity](https://oneworldidentity.com/) (OWI) CEO Travis Jarae to have a one-on-one conversation about [“The Rise & Adoption of Verifiable Credentials”](https://oneworldidentity.com/session/trinsic/). Below is a short summary
|
||||
|
||||
@ -4,6 +4,10 @@
|
||||
|
||||
A data NFT represents the copyright (or exclusive license against copyright) for a data asset on the blockchain — we call this the “base IP”. When a user publishes a dataset in OceanOnda V4, they create a new NFT as part of the process. This data NFT is proof of your claim of base IP. Assuming a valid claim, you are entitled to the revenue from that asset, just like a title deed gives you the right to receive rent.
|
||||
|
||||
* [NFTs, Verifiable Credentials, and Picos](https://www.windley.com/archives/2021/10/nfts_verifiable_credentials_and_picos.shtml) Phil Windley
|
||||
|
||||
Summary: The hype over NFTs and collectibles is blinding us to their true usefulness as trustworthy persistent data objects. How do they sit in the landscape with verifiable credentials and picos? Listening to this Reality 2.0 podcast about NFTs with Doc Searls, Katherine Druckman, and their guest Greg Bledsoe got me thinking about NFTs.
|
||||
|
||||
* [China is using #blockchain technology to manage #prisoners as if each #prisoner was an #NFT](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0147.html) Michael Herman (Trusted Digital Web) (Sunday, 26 December)
|
||||
|
||||
China is using #blockchain technology to manage #prisoners as if each #prisoner was an #NFT/token on the blockchain...
|
||||
|
||||
@ -29,8 +29,6 @@ Decentralized Identity & DeFi are Disconnected ← trueDecentralized Identity is
|
||||
- Credit, Income, KYC
|
||||
* [Circle and Industry Leaders Have Built the First Decentralized Identity Proof-of-Concept for Crypto Finance using Verite Credentials](https://www.circle.com/en/pressroom/circle-and-industry-leaders-have-built-the-first-decentralized-identity-proof-of-concept-for-crypto-finance-using-verite-credentials) Circle
|
||||
> Circle joined other crypto and blockchain companies in February 2022 to introduce Verite as a open-source framework for decentralized identity credential issuance, custody and verification. Verite is designed to help make it safer, easier and more efficient to do business across the transformative worlds of DeFi and Web3 commerce.
|
||||
* [Roadmap to Institutional Adoption of DeFi](https://www.youtube.com/watch?v%3DbkOQHcVVGoE) RSK - Coinfirm
|
||||
> The most recent FATF updated draft guidance from March 2021 introduces significant changes to the legal definition of DeFi platforms, expanding the types of entities that fall under FATF's umbrella. In this guidance, FATF defines most operators of decentralized finance platforms as “Virtual Asset Service Providers” that have AML/CFT obligations.
|
||||
* [DeFi regulation must not kill the values behind decentralization](https://cointelegraph.com/news/defi-regulation-must-not-kill-the-values-behind-decentralization) Cointelegraph
|
||||
> Financial Action Task Force (FATF) recently [proposed](https://www.fatf-gafi.org/publications/fatfrecommendations/documents/public-consultation-guidance-vasp.html) guidelines making it clear that “The owner/operator(s) of the DApp likely fall under the definition of a VASP [virtual asset service provider] [...] even if other parties play a role in the service or portions of the process are automated.
|
||||
* [InsideTheSimulation.eth @InsideTheSim Jul 28](https://twitter.com/InsideTheSim/status/1552636154423410689)
|
||||
|
||||
@ -864,9 +864,6 @@ A key opportunity Web3 presents in the identity space is the ability to interact
|
||||
|
||||
Decentralizing access to blockchain APIs is a vital step to improve network uptime and importantly, give people sovereignty of their personal data.
|
||||
|
||||
* [Ocean Protocol joins leading Web3 projects on the €20M+ Gaia-X moveID initiative to advance pan-European mobility](https://blog.oceanprotocol.com/ocean-protocol-joins-leading-web3-projects-on-the-20m-gaia-x-moveid-initiative-to-advance-72e4675d12d7) Ocean Protocol
|
||||
|
||||
Ocean Protocol, the Web3 platform to unlock data services for AI and business innovation, has joined forces with Chainstep, Datarella, Fetch.ai, peaq and 51nodes to develop the system architecture for European mobility with the preservation of data autonomy as its core principle, within the Gaia-X moveID project.
|
||||
|
||||
* [Dock’s Web3 ID Now Available on Auth0 Marketplace](https://blog.dock.io/docks-web3-id-now-available-on-auth0-marketplace/) Dock
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user