mirror of
https://github.com/Decentralized-ID/decentralized-id.github.io.git
synced 2024-12-16 19:14:33 -05:00
exchange protocols
This commit is contained in:
⧉ infominer
parent
9e6756b9dc
commit
a11ac125cf
@ -7,25 +7,21 @@
|
||||
- Methods ✓
|
||||
- ~~Resolution~~ Tools \ Services
|
||||
- Critique ✓
|
||||
|
||||
* [DIDs in DPKI](https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/dids-in-dpki.md)
|
||||
|
||||
|
||||
- Verifiable Credential
|
||||
- Explainer
|
||||
- Comparisons with/ other Tech
|
||||
- Verifiable Credential
|
||||
- Explainer ✓
|
||||
- Comparisons ✓
|
||||
- Varieties
|
||||
- JSON-LD
|
||||
- JSON-LD ZKP BBS+
|
||||
- JSON-JWT
|
||||
- ZKP-CL - [IIA] Indy Aries AnnonCreds
|
||||
- JWP
|
||||
- Exchange Protocols
|
||||
- DIDComm
|
||||
- CHAPI
|
||||
- OIDC
|
||||
- mDL
|
||||
- WACI-Pex
|
||||
- Exchange Protocols ✓
|
||||
- DIDComm ✓
|
||||
- CHAPI ✓
|
||||
- OIDC ✓
|
||||
- mDL ✓
|
||||
- WACI-Pex ✓
|
||||
- Complementary to VC/DID Standards
|
||||
- JSON-LD
|
||||
- JSON
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
# Decentralized Identity Foundation
|
||||
|
||||
* [Sidetree Spec V1.0.0](https://identity.foundation/sidetree/spec/) Working Group approved status
|
||||
* [WACI (Wallet And Credential Interaction)](https://identity.foundation/wallet-and-credential-interactions/)
|
||||
|
||||
@ -22,9 +22,6 @@ published: false
|
||||
- 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.
|
||||
* [CREATE AN OIDC CREDENTIAL ISSUER WITH MATTR AND ASP.NET CORE](https://damienbod.com/2021/05/03/create-an-oidc-credential-issuer-with-mattr-and-asp-net-core/)
|
||||
|
||||
This article shows how to create and issue verifiable credentials using [MATTR](https://mattr.global/) and an [ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/introduction-to-aspnet-core). The ASP.NET Core application allows an admin user to create an OIDC credential issuer using the MATTR service. The credentials are displayed in an ASP.NET Core Razor Page web UI as a QR code for the users of the application.
|
||||
|
||||
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/)
|
||||
@ -103,9 +100,8 @@ Peers would still use their peer ID for [libp2p](https://libp2p.io/) routing an
|
||||
* [Introducing New Tools for Creators to Build Trusted Communities](https://www.civic.com/blog/introducing-new-tools-for-creators-to-build-trusted-communities/) CIVIC
|
||||
|
||||
Our goal is to make the process of building trust easier and more effective for creators. With that in mind, we’re sharing an overview of our plan to address the pain points of creators and marketplaces in the NFT space using identity tools.
|
||||
* [Use CodeB SSI as OpenID Connect Identity Provider for WordPress](https://blog.codeb.io/use-codeb-ssi-as-oidc-identity-provider-for-wordpress/) CodeB
|
||||
|
||||
The Self-Sovereign Identity System of CodeB does not only support W3C DID’s but comes also with an inbuilt OpenID Connect (OIDC) Identity Provider. [OpenID Connect meets distributed Self-Sovereign Identities.](https://www.codeb.io/openid-connect-meets-distributed-self-sovereign-identities/)
|
||||
|
||||
|
||||
* [An authentication system built with Ceramic & self.id](https://github.com/dabit3/decentralized-identity-example) dabit3
|
||||
|
||||
@ -255,8 +251,6 @@ This is so exciting to see what Wayne and his team are building.
|
||||
> DID:Key, originally specified in the W3C Credentials Community Group (CCG), is a DID “pseudo-method” that allows static, pre-existing, and/or pre-published public keys to function like traditional DIDs — they can be queried, stored, issued against, and resolved to return valid DID documents.
|
||||
* [DIDKit v0.1 is Live.](https://sprucesystems.medium.com/didkit-v0-1-is-live-d0ea6638dbc9)
|
||||
> Most other options are subtly locked to a specific blockchain and its particularities, which a self-sovereign identity (SSI) novice is unlikely to notice until months into a project based on it. A few open-source libraries exist to sidestep this infrastructural lock-in, but these are more like primitives for assembling an SSI toolkit than ready-to-go, developer-friendly libraries. DIDKit, on the other hand, is ready to start processing real-world VCs with non-repudiable signatures right out the box.
|
||||
* [Rust KERI implementation](https://github.com/decentralized-identity/keriox/) Jolocom
|
||||
> We at Jolocom strongly believe that DIDComm is a crucial infrastructure element for the broader and future-proof SSI stack, and current work on [DIDComm v2](https://identity.foundation/didcomm-messaging/spec/) includes Jolocom’s implementation of the specification with authcrypt (authenticated encrypted) and most of the low level of the protocol.
|
||||
|
||||
* [Aries Mobile Agent SDK for Google Flutter](https://ayanworks.medium.com/announcing-arnima-fl-open-source-aries-flutter-mobile-agent-sdk-d3483744ffc8)
|
||||
> Exactly a year ago in Jan 2020, we announced ARNIMA — first ever Aries React Native Mobile Agent SDK that we made open source for the Self-Sovereign Identity ecosystem.
|
||||
@ -385,9 +379,7 @@ Rooted in a “trust but verify” mindset, several Canadian public sector entit
|
||||
|
||||
► [Credentials as a Service Providing Self Sovereign Identity as a Cloud Service Using Trusted Execution Environments](https://ieeexplore.ieee.org/document/9610297)
|
||||
|
||||
* [Spruce Developer Update #20](https://blog.spruceid.com/spruce-developer-update-20/)
|
||||
|
||||
We've set up a [release pipeline](https://github.com/spruceid/ens-oidc/) and had our first witnessed deployment for the ENS Community-Maintained OIDC IdP ([more info here](https://blog.spruceid.com/sign-in-with-ethereum-decentralizing-an-identity-provider-server/)
|
||||
|
||||
Updates on Kepler including implementing support for [CACAO-ZCAPs](https://github.com/spruceid/cacao-zcap), improved the `put` function to make it easier to store objects of different types, and added support for listing objects by prefix: [kepler-sdk#40](https://github.com/spruceid/kepler-sdk/pull/40) [kepler#115](https://github.com/spruceid/kepler/pull/115).
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ W3C Web Authentication (FIDO2) provides a mechanism for strong authentication wh
|
||||
|
||||
Prof. David Chadwick presented work on sharing W3C Verifiable Crendentials via FIDO2 key setup with issuers of credentials. In a nutshell, the holder and issuer use the WebAuthN protocol to strongly authenticate before the issuer protects the credentials with its signature. Upon providing credentials to a relying party, the issuer (acting in an IDP capacity, so they must be online) will verify the identity of the holder via FIDO2 WebAuthN so that the credentials (or selected claims in the credentials for selective disclosure) can be shared with the relying party. Ephemeral keys are created to bind the holder with such credentials shared to the relying party/verifier. The relying party/verifier can use X.509 certs to confirm that the issuer is valid by checking the signature on the derived credential from the holder.
|
||||
|
||||
* [Use-cases: OIDC for Verifiable Credentials - How do you want to use Identity Provider you control?](https://iiw.idcommons.net/12G/_Use-cases:_OIDC_for_Verifiable_Credentials_-_How_do_you_want_to_use_Identity_Provider_you_control%253F) by Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker
|
||||
|
||||
|
||||
* [SIOP Use-cases - IIW Spring 2021](https://docs.google.com/presentation/d/1a0C4HvVYwwwDqSw3tgPNhy9Iqyufy9oZdnMgl7rQ9Vc/edit%23slide%3Did.p)
|
||||
|
||||
|
||||
@ -68,3 +68,13 @@ This development is possible due to the fact that BBS+ signatures is a ledger-in
|
||||
> 2. It made it possible to store a cred def somewhere other than a ledger
|
||||
> I was very happy about this.
|
||||
> However, I have since heard several smart people summarize the breakthrough as: "We don't need credential definitions at all. You just use the assertionMethod key in your DID doc to sign credentials, and that's all you need." I believe this is oversimplifying in a way that loses something important, so I wanted to open a conversation
|
||||
|
||||
## Jose-Cose
|
||||
|
||||
* [Two new COSE- and JOSE-related Internet Drafts with Tobias Looker](https://self-issued.info/?p%3D2260) Mike Jones
|
||||
> This week, [Tobias Looker](https://twitter.com/tplooker) and I submitted two individual Internet Drafts for consideration by the [COSE working group](https://datatracker.ietf.org/wg/cose/about/).
|
||||
* [XMSS: Generating usable test vectors for JOSE and COSE](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0007.html) Orie Steele (Sunday, 3 April)
|
||||
|
||||
We've been working on generating test vectors for: [https://datatracker.ietf.org/doc/html/rfc8391](https://datatracker.ietf.org/doc/html/rfc8391) $1$2
|
||||
|
||||
That we could use to register the `kty` and `alg` for XMSS such that it could be used by JOSE and COSE.
|
||||
|
||||
@ -1,84 +0,0 @@
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
# DIDComm
|
||||
|
||||
* [DID Comm has its own site](https://didcomm.org/)
|
||||
> DIDComm lets people and software use [DIDs](https://www.w3.org/TR/did-core/) to communicate securely and privately over many channels: the web, email, mobile push notifications, QR codes, Bluetooth, message queues, sneakernet, and more.
|
||||
* [Why the Internet Needs DIDComm](https://iiw.idcommons.net/2D/_Why_the_Internet_Needs_DIDComm) by Sam Curren
|
||||
|
||||
* [https://docs.google.com/presentation/d/16HTPyZV_-BtM6EifQpxjivRHKYUeVtOAReUD1eGUA9M/edit?usp=sharing](https://docs.google.com/presentation/d/16HTPyZV_-BtM6EifQpxjivRHKYUeVtOAReUD1eGUA9M/edit?usp%3Dsharing)
|
||||
|
||||
- Enables Verifiable Communication
|
||||
- Intelligence at the edge (like email)
|
||||
- Protocol Based (like email)
|
||||
- Supports HTTP(s) (like APIs) and others as a transport
|
||||
- Bluetooth enables Edge to Edge transport
|
||||
- Mobile / Offline Friendly (like email)
|
||||
- Supports rotating from one DID to another
|
||||
- Security independent of transport
|
||||
- Protocol development becomes easier and more robust (unlike email)
|
||||
|
||||
- [https://identity.foundation/](https://identity.foundation/)
|
||||
- [#wg-didcomm on DIF Slack](https://difdn.slack.com)
|
||||
- [https://identity.foundation/didcomm-messaging/docs/spec/](https://identity.foundation/didcomm-messaging/docs/spec/)
|
||||
- [https://github.com/decentralized-identity/didcomm-messaging](https://github.com/decentralized-identity/didcomm-messaging)
|
||||
- WG Calls Mondays at noon US/Pacific ([Agenda](https://github.com/decentralized-identity/didcomm)
|
||||
|
||||
* [Decentralized Semantics 101](https://iiw.idcommons.net/2E/_Decentralized_Semantics_101) by Paul Knowles
|
||||
|
||||
The form of the session was a presentation (intended for those new to the subject), followed by Q/A and discussion
|
||||
|
||||
Presentation: [Decentralized Semantics 101](https://drive.google.com/file/d/1Og1LVND8RrHbZ8mBobBehRzN46YI4SXt/view?usp%3Dsharing)
|
||||
|
||||
A digital network must contain authenticable data entry and immutable data
|
||||
|
||||
capture elements in order to maintain balance and integrity.
|
||||
|
||||
Within the context of a decentralized network, these fundamentals enable a self-regulating system where ...
|
||||
|
||||
(1) data inputs can be trusted as having come from an assured source under the control of a governing entity; and
|
||||
|
||||
(2) semantic items ensure that the meaning and use of inputted data remains unaltered for all interacting actors.
|
||||
|
||||
Vocabulary:
|
||||
|
||||
- Form - taken from paper forms used filled in by subjects and service provider reps (e.g., clinician). A Form is a composite/aggregate packaging of claims/attributes from one or more Verifiable Credentials (VCs) for presentation (e.g., to a verifier) or for data exchange.
|
||||
|
||||
* [DIDComm v2: Implementation and integration](https://iiw.idcommons.net/11D/_DIDComm_V2:_Implementation_and_integration_%2527technical%2527_-_did:key_and_did:keri_resolvers,_seamless_and_partial_integrations-)
|
||||
|
||||
* [Didcomm-rs.pdf](https://drive.google.com/file/d/1dn5f2SqnCeQocOy5quJD9gpMPipKRmdC/view?usp%3Dsharing)
|
||||
|
||||
- DIDComm v2 spec: [https://identity.foundation/didcomm-messaging/spec](https://identity.foundation/didcomm-messaging/spec)
|
||||
- didcomm-rs: [https://github.com/decentralized-identity/didcomm-rs](https://github.com/decentralized-identity/didcomm-rs)
|
||||
• ddoresolver-rs: [https://github.com/jolocom/ddoresolver-rs](https://github.com/jolocom/ddoresolver-rs)
|
||||
• keriox: [https://github.com/decentralized-identity/keriox](https://github.com/decentralized-identity/keriox) creds to Charles Cunningham, Edyta Pawlak and other contributors.
|
||||
- did-key: [https://crates.io/crates/did-key](https://crates.io/crates/did-key) creds to Tomislav Markovski.
|
||||
- DIF F2F demo session: [https://www.youtube.com/watch?v=SaNvIorKQ9I](https://www.youtube.com/watch?v%3DSaNvIorKQ9I)
|
||||
|
||||
* [DIDComm and the Self-Sovereign Internet](https://iiw.idcommons.net/21A/_DIDComm_and_the_Self-Sovereign_Internet) by Phil Windley
|
||||
|
||||
* [https://docs.google.com/presentation/d/1h0qi2qyGwM30DHpRAXW_Y0bBneo9xMEFZh1rIAeRa-E/edit?usp=sharing](https://docs.google.com/presentation/d/1h0qi2qyGwM30DHpRAXW_Y0bBneo9xMEFZh1rIAeRa-E/edit?usp%3Dsharing)
|
||||
|
||||
Summary: DIDComm is the messaging protocol that provides utility for DID-based relationships. DIDComm is more than just a way to exchange credentials, it's a protocol layer capable of supporting specialized application protocols for specific workflows. Because of its general nature and inherent support for self-sovereign relationships, DIDComm provides a basis for a self-sovereign internet much more private, enabling, and flexible than the one we've built using Web 2.0 technologies.
|
||||
|
||||
DID-based relationships are the foundation of self-sovereign identity (SSI). The exchange of DIDs to form a connection with another party gives both parties a relationship that is self-certifying and mutually authenticated. Further, the connection forms a secure messaging channel called DID Communication or DIDComm. DIDComm messaging is more important than most understand, providing a secure, interoperable, and flexible general messaging overlay for the entire internet.
|
||||
|
||||
* [DIDComm and the Self-Sovereign Internet - Phillip J. Windley, Ph.D., Brigham Young University](https://www.windley.com/archives/2020/11/didcomm_and_the_self-sovereign_internet.shtml)
|
||||
|
||||
DIDComm is a protocol layer capable of supporting specialized application protocols for specific workflows. Because of its general nature and inherent support for self-sovereign relationships, DIDComm provides a basis for a self-sovereign internet much more private, enabling, and flexible than the one we've built using Web 2.0 technologies. This talk introduces DIDComm, discusses its protocological nature, and presents use cases in the Internet of Things. Demonstrations of DIDComm protocol interactions will be shown on the Pico platform, which implements the Aries Cloud Agent (ACA) specification.
|
||||
|
||||
|
||||
* [Why we need DIDComm](https://identitywoman.net/why-we-need-didcomm/) IdentityWoman
|
||||
|
||||
This is the text of an email I got today from a company that I had a contract with last year [...] I was reminded quite strongly why we need DIDComm as a protocol to enable the secure transport of all sorts of things not just signed VCs but intermediate uses
|
||||
* [Two new COSE- and JOSE-related Internet Drafts with Tobias Looker](https://self-issued.info/?p%3D2260) Mike Jones
|
||||
|
||||
This week, [Tobias Looker](https://twitter.com/tplooker) and I submitted two individual Internet Drafts for consideration by the [COSE working group](https://datatracker.ietf.org/wg/cose/about/).
|
||||
|
||||
* [The Missing Network Layer Model](https://findy-network.github.io/blog/2022/03/05/the-missing-network-layer-model/) Findy
|
||||
|
||||
Epic Post
|
||||
|
||||
You might think that I have lost my mind. We have just reported that our Indy SDK based DID agency is [AIP 1.0](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0302-aries-interop-profile/README.md) compatible, and everything is wonderful. What’s going on?
|
||||
@ -0,0 +1,63 @@
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
# DIDComm
|
||||
|
||||
* [DIDComm has its own site](https://didcomm.org/)
|
||||
> DIDComm lets people and software use [DIDs](https://www.w3.org/TR/did-core/) to communicate securely and privately over many channels: the web, email, mobile push notifications, QR codes, Bluetooth, message queues, sneakernet, and more.
|
||||
- [DIDComm](https://identity.foundation/working-groups/did-comm.html) Identity Foundation
|
||||
- [#wg-didcomm on DIF Slack](https://difdn.slack.com)
|
||||
- [decentralized-identity/didcomm-messaging](https://github.com/decentralized-identity/didcomm-messaging) GitHub
|
||||
- WG Calls Mondays at noon US/Pacific ([Agenda](https://github.com/decentralized-identity/didcomm)
|
||||
|
||||
## Specifications
|
||||
|
||||
- [DIDComm Messaging v2.x Editor’s Draft](https://identity.foundation/didcomm-messaging/docs/spec/) Identity Foundation
|
||||
- [DIDComm v2 spec](https://identity.foundation/didcomm-messaging/spec)
|
||||
|
||||
|
||||
## Explainer
|
||||
* [Why the Internet Needs DIDComm](https://iiw.idcommons.net/2D/_Why_the_Internet_Needs_DIDComm) by Sam Curren [presentation](https://docs.google.com/presentation/d/16HTPyZV_-BtM6EifQpxjivRHKYUeVtOAReUD1eGUA9M/edit?usp%3Dsharing)
|
||||
> - Enables Verifiable Communication
|
||||
> - Intelligence at the edge (like email)
|
||||
> - Protocol Based (like email)
|
||||
> - Supports HTTP(s) (like APIs) and others as a transport
|
||||
> - Bluetooth enables Edge to Edge transport
|
||||
> - Mobile / Offline Friendly (like email)
|
||||
> - Supports rotating from one DID to another
|
||||
> - Security independent of transport
|
||||
> - Protocol development becomes easier and more robust (unlike email)
|
||||
* [Decentralized Semantics 101](https://iiw.idcommons.net/2E/_Decentralized_Semantics_101) by Paul Knowles [Presentation](https://drive.google.com/file/d/1Og1LVND8RrHbZ8mBobBehRzN46YI4SXt/view?usp%3Dsharing)
|
||||
> A digital network must contain authenticable data entry and immutable data
|
||||
>
|
||||
> capture elements in order to maintain balance and integrity.
|
||||
>
|
||||
> Within the context of a decentralized network, these fundamentals enable a self-regulating system where ...
|
||||
>
|
||||
> (1) data inputs can be trusted as having come from an assured source under the control of a governing entity; and
|
||||
>
|
||||
> (2) semantic items ensure that the meaning and use of inputted data remains unaltered for all interacting actors.
|
||||
* [DIDComm and the Self-Sovereign Internet](https://iiw.idcommons.net/21A/_DIDComm_and_the_Self-Sovereign_Internet) by Phil Windley [presentation](https://docs.google.com/presentation/d/1h0qi2qyGwM30DHpRAXW_Y0bBneo9xMEFZh1rIAeRa-E/edit?usp%3Dsharing)
|
||||
> DID-based relationships are the foundation of self-sovereign identity (SSI). The exchange of DIDs to form a connection with another party gives both parties a relationship that is self-certifying and mutually authenticated. Further, the connection forms a secure messaging channel called DID Communication or DIDComm. DIDComm messaging is more important than most understand, providing a secure, interoperable, and flexible general messaging overlay for the entire internet.
|
||||
* [DIDComm and the Self-Sovereign Internet - Phillip J. Windley, Ph.D., Brigham Young University](https://www.windley.com/archives/2020/11/didcomm_and_the_self-sovereign_internet.shtml)
|
||||
> DIDComm is a protocol layer capable of supporting specialized application protocols for specific workflows. Because of its general nature and inherent support for self-sovereign relationships, DIDComm provides a basis for a self-sovereign internet much more private, enabling, and flexible than the one we've built using Web 2.0 technologies. This talk introduces DIDComm, discusses its protocological nature, and presents use cases in the Internet of Things. Demonstrations of DIDComm protocol interactions will be shown on the Pico platform, which implements the Aries Cloud Agent (ACA) specification.
|
||||
* [Why we need DIDComm](https://identitywoman.net/why-we-need-didcomm/) IdentityWoman
|
||||
> This is the text of an email I got today from a company that I had a contract with last year [...] I was reminded quite strongly why we need DIDComm as a protocol to enable the secure transport of all sorts of things not just signed VCs but intermediate uses
|
||||
|
||||
|
||||
## Development
|
||||
* [DIDComm v2: Implementation and integration](https://iiw.idcommons.net/11D/_DIDComm_V2:_Implementation_and_integration_%2527technical%2527_-_did:key_and_did:keri_resolvers,_seamless_and_partial_integrations-)
|
||||
* [didcomm-rs implementation](https://drive.google.com/file/d/1dn5f2SqnCeQocOy5quJD9gpMPipKRmdC/view?usp%3Dsharing) presentation
|
||||
- [decentralized-identity/didcomm-rs](https://github.com/decentralized-identity/didcomm-rs) github
|
||||
|
||||
## Real World
|
||||
- [DIF F2F demo session](https://www.youtube.com/watch?v%3DSaNvIorKQ9I)
|
||||
|
||||
|
||||
|
||||
* [The Missing Network Layer Model](https://findy-network.github.io/blog/2022/03/05/the-missing-network-layer-model/) Findy
|
||||
|
||||
Epic Post
|
||||
|
||||
You might think that I have lost my mind. We have just reported that our Indy SDK based DID agency is [AIP 1.0](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0302-aries-interop-profile/README.md) compatible, and everything is wonderful. What’s going on?
|
||||
@ -0,0 +1,306 @@
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
# Credential Exchange
|
||||
|
||||
* [Figuring out Verifiable Credentials Exchange - combining Bloom, Aires Protocols, Presentation Exchange into a unified - Killer Whale Jello Salad](https://iiw.idcommons.net/22H/_Figuring_out_Verifiable_Credentials_Exchange_-_combining_Bloom,_Aires_Protocols,_Presentation_Exchange_into_a_unified_-_Killer_Whale_Jello_Salad) by Kaliya Young, Orie Steele, Drummond , Kyle et al [ [presentation](https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit%23slide%3Did.p)]
|
||||
> - Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
|
||||
> - Goal to create a bridge between
|
||||
> - the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
|
||||
> - Aries protocols run on top of DIDComm
|
||||
> - If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
|
||||
> - Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
|
||||
> - So can be tested with next SVIP - testing.
|
||||
> - Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
|
||||
> - Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
|
||||
> - Potentially quickly spinning up a working group at DIF - Decision was to nest within the Credentials and Claims group at DIF
|
||||
> Result: [https://identity.foundation/arewewaciyet/](https://identity.foundation/arewewaciyet/)
|
||||
|
||||
|
||||
* [BBS+ Credential Exchange in Hyperledger Aries](https://iiw.idcommons.net/11E/_BBS%252B_Credential_Exchange_in_Hyperledger_Aries) [[presentation](https://iiw.animo.id)]
|
||||
|
||||
* [Credentials Exchange - figuring it out - (Jello Bowl Death Match?)](https://iiw.idcommons.net/12F/_Credentials_Exchange_-_figuring_it_out_-_(Jello_Bowl_Death_Match%253F)_%25E2%2580%2593) [[Slides](https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit%23slide%3Did.p)]
|
||||
DIDComm, Verifiable Credential Exchange, Aries Protocol, Bloom Protocol, Presentation Exchange
|
||||
|
||||
The ultimate goal is to get to a clear exchange protocols.
|
||||
|
||||
Also to have a paper similar to this one that outlines the choice landscape that is and points to a convergence point - [https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf)
|
||||
|
||||
Good Health Pass is literally right now trying to figure this out and will “pick” solutions it needs to get implementations working in the next 30-90 days and point the whole industry in one direction.
|
||||
|
||||
We started out with this framework of understanding
|
||||
|
||||
Contextualizing VC Exchange in Layers
|
||||
|
||||
Verifiable Credentials (VC or VCs) is one of the key standardized components of decentralized identity. [The VCs Data Model](https://www.w3.org/TR/vc-data-model/), defined at the W3C, is a universal data format that lets any entity express anything about another entity. It provides a common mechanism for the interoperable implementation of digital credentials that are cryptographically secure, tamper-evident, privacy-respecting, and machine-verifiable.
|
||||
|
||||
There clarity emerging on standards that are interoperable with one another for the VC format.
|
||||
|
||||
There is less clarity on the Exchange mechanisms.
|
||||
|
||||
One way that has been proposed to look at the exchange options available is to see them in different layers.
|
||||
|
||||
* [Aries RFC 0453 - credential issuance protocol using DIDComm V1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2)
|
||||
|
||||
* [Aries RFC 0454 - Present Proof protocol V2 using DIDCommV1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0454-present-proof-v2)
|
||||
|
||||
### DIDComm v2
|
||||
|
||||
Work Item within DIF right now - envelope format with some other opinions we may or may want. Daniel Hardman gave vision - of parts that are done - leaving behind parts not done.
|
||||
|
||||
- DIDCom V2 Envelops JWEs (a standard that exists)
|
||||
- Aries RFCs for payloads that go in JWE envelopes.
|
||||
- Send envelopes over HTTP as a starting point
|
||||
|
||||
### CHAPI
|
||||
|
||||
The Credential Handler API or CHAPI is currently a draft community group report developed by/under the Credentials Community Group at the W3C. At the heart of this model is a credential repository which is a Web application that can handle credential requests and credential storage on behalf of the user/holder. The API Is designed to support the transmission of credentials between a web based issuer and a holder with a cloud wallet (credential repository) that is visible in the same browser but in a different tab. It creates a “dumb pipe” between the two tabs in the holder’s browser and permits the transmition of the credential effectively from one tab to another.
|
||||
* [chapi.io launches, includes VC playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html) Manu Sporny CCG
|
||||
|
||||
TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.
|
||||
|
||||
* [TrustBloc - Duty Free Shop use case (CHAPI Save + WACI Share)](https://www.youtube.com/watch?v%3DaagFJBI1fBE)
|
||||
|
||||
This video demonstrates the TrustBloc platform to Issue a W3C Verifiable Credential through CHAPI and Share the Verifiable Credential/Presentation through WACI.
|
||||
|
||||
|
||||
CHAPI
|
||||
|
||||
* [VC-API Diagram for today. Focus on CHAPI](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0007.html) Joe Andrieu (Tuesday, 2 November)
|
||||
|
||||
|
||||
|
||||
* [chapi.io launches, includes VC playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html) Manu Sporny (Monday, 27 June)
|
||||
|
||||
TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.
|
||||
|
||||
* [chapi.io playground upgrades - credential selector, resident card](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0111.html) Manu Sporny (Wednesday, 27 July)
|
||||
|
||||
The credential selector is an icon-based selector for all the credentials that the chapi.io playground currently supports issuing. You can now click on an image of the credential you'd like to issue.
|
||||
|
||||
* [...]
|
||||
|
||||
We have added a permanent resident card from the fictitious Government of Utopia to the list of credentials that can be issued. This credential uses the Citizenship Vocabulary[...]
|
||||
|
||||
* [You can try both of these new features out in the playground](https://playground.chapi.io/issuer)
|
||||
|
||||
* [Jobs For The Future VC added to chapi.io playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0031.html) Manu Sporny (Wednesday, 13 July)
|
||||
|
||||
TL;DR: In an attempt to support the current Jobs for the Future Plugfest, an Open Badge v3.0 example for an Academic Achievement has been added to the chapi.io playground. You can now see what a JFF badge issuance and transfer to a Holder wallet looks like in CHAPI (on mobile and web, on any device that can run a web browser). Images of the flow are attached.
|
||||
|
||||
### VC-HTTP-API (VHA)
|
||||
|
||||
The VC HTTP is a RESTful API specification (conforming with the [OpenAPI](https://swagger.io/specification/) [3.0 Specification](https://swagger.io/specification/) for constructing and verifying objects which conform to the Verifiable Credential Data Model specification.
|
||||
|
||||
A bit more about the OpenAPI 3.0 specification itself:
|
||||
|
||||
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
|
||||
|
||||
This API is versioned in conformance with the [Semantic Versioning 2.0 specification](https://semver.org/) to prevent breaking changes between minor versions, and to allow for reliable testing and integration of implementations of this API within enterprise environments. This API provides a standard set of interfaces by which interoperability may be tested and verified by various parties who leverage Verifiable Credentials (VCs).
|
||||
|
||||
This slide, from a slide deck presentation by Manu Sporny to the W3C Credentials Community Group on 20 April 2021, explains the relationship of the VC-HTTP-API to CHAPI:
|
||||
|
||||
### WACI
|
||||
|
||||
There are interactions between a wallet and relying party that require passing information between the two. WACI provides a standard for these interactions.
|
||||
|
||||
* [https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0/#status-of-this-document](https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0/%23status-of-this-document)
|
||||
|
||||
WACI bound to JWT - signed. Could be JWE technically (would have to know the other parties DID and Keys - only optionally required here).
|
||||
|
||||
Fully supports credential manifest and presentation exchange.
|
||||
|
||||
Could be bound to DIDComm
|
||||
* [Introducing: WACI (Wallet And Credential Interaction)](https://iiw.idcommons.net/4K/_Introducing:_WACI_(Wallet_And_Credential_Interaction)) by Jace Hensley
|
||||
|
||||
* [https://specs.bloom.co/wallet-and-credential-interactions/](https://specs.bloom.co/wallet-and-credential-interactions/)
|
||||
|
||||
* [https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0](https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0)
|
||||
|
||||
Orie linked this related github issue and discussion:[https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84](https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84)
|
||||
Also related: [https://w3c-ccg.github.io/vp-request-spec/#format](https://w3c-ccg.github.io/vp-request-spec/%23format)
|
||||
|
||||
Use cases support mobile wallets, backend services and web apps.
|
||||
Supports chaining of requests…. Relies on credential manifest and presentation exchange
|
||||
|
||||
W3C CCG work seems focussed on the “vc-http-api” and “vp-request-spec” as the solutions to this problem…
|
||||
We reviewed IoT / Web / API considerations for presentation exchange.
|
||||
We notes the following hypothetically viable non interoperable solutions to this problem:
|
||||
1. DIDComm v1 (IIW ticket flows?)
|
||||
2. vp-request-spec + CHAPI
|
||||
|
||||
3. vc-http-api + …. ? / w3c ccg traceability API.
|
||||
|
||||
4. OIDF vp-token spec?
|
||||
* [WACI (Wallet And Credential Interaction)](https://identity.foundation/wallet-and-credential-interactions/)
|
||||
|
||||
### Message Format
|
||||
|
||||
Presentation Exchange defined in DIF
|
||||
|
||||
Presentation Exchange is a protocol to support the interaction between holders and verifiers. It supports them being able to express what combination of credential the verifier wants or needs.
|
||||
|
||||
Credential Manifest as defined in DIF
|
||||
|
||||
Asking for a presentation
|
||||
|
||||
And asking proof to enable issuing a credential.
|
||||
|
||||
Indy Proof Request
|
||||
|
||||
Aries Exchange Protocol
|
||||
|
||||
Define the messages that go back and forth between
|
||||
|
||||
Issuer and holder (4 messages)
|
||||
|
||||
Holder and Verifier (3 messages)
|
||||
|
||||
Different formats (types of credentials) are different attachments in those messages.
|
||||
|
||||
DIDComm v1, there is AIP v1 and AIP v2 :)
|
||||
|
||||
Where does it go?
|
||||
|
||||
### OIDC-SOIP
|
||||
|
||||
Self-Issued OpenID Connect Provider or OIDC-SOIP was created to take advantage of the fact that there are several 100,000 implementations of OpenID Connect on todays web. This method of exchange verifiable credentials leverages that infrastructure with a few small changes to support OpenID enabled sites to be able to accept verifiable credentials. Holders have wallets or agents that they use to interact with a system. The protocols to do this are being worked on jointly by the OpenID Foundation and Decentralized Identity Foundation.
|
||||
|
||||
* [OIDC Credential Provider](https://medium.com/mattr-global/introducing-oidc-credential-provider-7845391a9881) Mattr Global. Dec 15, 2000
|
||||
* [State of identity on the web](https://medium.com/mattr-global/the-state-of-identity-on-the-web-cffc392bc7ea) Mattr Global. March 14, 2021
|
||||
|
||||
Current MATTR spec for OpenID Credential Exchange: [OpenID Connect Credential Provider](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/)
|
||||
|
||||
* [More Killer Whale Jello Salad…figuring out how credential exchange can harmonize.](https://iiw.idcommons.net/24B/_More_Killer_Whale_Jello_Salad...figuring_out_how_credential_exchange_can_harmonize.) by Kaliya Young et al.
|
||||
> - Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
|
||||
> - Goal to create a bridge between
|
||||
> - the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
|
||||
> - Aries protocols run on top of DIDComm
|
||||
> - If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
|
||||
> - Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
|
||||
> - So can be tested with next SVIP - testing.
|
||||
> - Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
|
||||
> - Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
|
||||
* [OpenID Connect Presentation at IIW XXXII](https://self-issued.info/?p%3D2167)
|
||||
- [OpenID Connect](https://openid.net/connect/)
|
||||
- [Frequently Asked Questions](https://openid.net/connect/faq/)
|
||||
- [Working Group Mailing List](https://lists.openid.net/mailman/listinfo/openid-specs-ab)
|
||||
- [OpenID Certification Program](https://openid.net/certification/)
|
||||
- [Certified OpenID Connect Implementations Featured for Developers](https://openid.net/developers/certified/)
|
||||
* [OpenID Connect Credential Provider](https://medium.com/mattr-global/introducing-oidc-credential-provider-7845391a9881) Mattr
|
||||
* [OIDC Credential Provider](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/) is “an extension to OpenID Connect which enables the end-user to request credentials from an OpenID Provider and manage their own credentials in a digital wallet.”
|
||||
* [CREATE AN OIDC CREDENTIAL ISSUER WITH MATTR AND ASP.NET CORE](https://damienbod.com/2021/05/03/create-an-oidc-credential-issuer-with-mattr-and-asp-net-core/)
|
||||
> This article shows how to create and issue verifiable credentials using [MATTR](https://mattr.global/) and an [ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/introduction-to-aspnet-core). The ASP.NET Core application allows an admin user to create an OIDC credential issuer using the MATTR service. The credentials are displayed in an ASP.NET Core Razor Page web UI as a QR code for the users of the application.
|
||||
* [Use CodeB SSI as OpenID Connect Identity Provider for WordPress](https://blog.codeb.io/use-codeb-ssi-as-oidc-identity-provider-for-wordpress/) CodeB
|
||||
|
||||
The Self-Sovereign Identity System of CodeB does not only support W3C DID’s but comes also with an inbuilt OpenID Connect (OIDC) Identity Provider. [OpenID Connect meets distributed Self-Sovereign Identities.](https://www.codeb.io/openid-connect-meets-distributed-self-sovereign-identities/)
|
||||
* [Spruce Developer Update #20](https://blog.spruceid.com/spruce-developer-update-20/)
|
||||
|
||||
We've set up a [release pipeline](https://github.com/spruceid/ens-oidc/) and had our first witnessed deployment for the ENS Community-Maintained OIDC IdP ([more info here](https://blog.spruceid.com/sign-in-with-ethereum-decentralizing-an-identity-provider-server/)
|
||||
* [Use-cases: OIDC for Verifiable Credentials - How do you want to use Identity Provider you control?](https://iiw.idcommons.net/12G/_Use-cases:_OIDC_for_Verifiable_Credentials_-_How_do_you_want_to_use_Identity_Provider_you_control%253F) by Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker
|
||||
* [Browser APIs to enable OpenID Session Management and Privacy](https://iiw.idcommons.net/13L/_Browser_APIs_to_enable_OpenID_Session_Management_and_Privacy) by Sam Goto
|
||||
|
||||
How does logout in OIDC happen?
|
||||
|
||||
- Classification problem - browsers do not know it is a logout now
|
||||
- Easiest way
|
||||
- Browser asks for a user consent
|
||||
- Hard from a permission implementation perspective
|
||||
- Tim: No issues with this idea
|
||||
- If user logged into several OPs, user will not look to all the ones they log out from
|
||||
- Option2
|
||||
- Browser classifies signing-in event
|
||||
- On log out does not prompt the user and IdP has no incentives to lie
|
||||
- RPs get to determine if they want to log the user out or not
|
||||
- Whether you can swap generic frame with fenced frame, frame can see it’s own cookies
|
||||
- May not be able to pass any parameters that you need to pass; no link decoration for framed frame
|
||||
- Subdomains also considered, but not well thought out
|
||||
- Logout URL - other option to add, but more work for RP: Resource metadata. Specification - not much adoption. It just feels like a place where RP metadata could be declared which could be useful in this context of the RP defining its metadata (e.g. what IDP it uses
|
||||
- [draft-jones-oauth-resource-metadata-01 - OAuth 2.0 Protected Resource Metadata (ietf.org)](https://tools.ietf.org/html/draft-jones-oauth-resource-metadata-01)
|
||||
- On digression: [https://cloudidentity.com/blog/wp-content/uploads/2013/01/3252.image_5F00_04277494.png](https://cloudidentity.com/blog/wp-content/uploads/2013/01/3252.image_5F00_04277494.png)
|
||||
- Messy real-life situation - sign in to AAD with OIDC and WS-fed; register something at sign-in. From a user, same account, does not matter which protocol is used
|
||||
- What needs more to be discussed what log out means to the user
|
||||
- User does not understand when they log out from office, they also log out from Azure
|
||||
- Also a developer choice
|
||||
- Relevant one, but not much browsers can do about
|
||||
- If a bigger picture is browser wants to be in the middle, browser can do something in this area too.
|
||||
- Ugly part of logout - mechanisms to allow the range of services
|
||||
- IdP does not need to send back list of all RPs user is logging out from
|
||||
- Idea not entirely off for IdP to tell a browser from there it wants to log user out from
|
||||
- Browser have confident of the user intent
|
||||
- Prompt the user for the intent - never a good idea
|
||||
- Logout API that community can control a behaviour of
|
||||
- You call it, browser logs it, and tell where the user left of
|
||||
- Browser observes the login - passively. Heuristics - what if the browser has not seen it..
|
||||
- some of this is already starting to show up in chrome canarie
|
||||
- [https://chromium-review.googlesource.com/c/chromium/src/+/2837551](https://chromium-review.googlesource.com/c/chromium/src/%2B/2837551)
|
||||
- If domain name ETLD of the issuer is the same as IdP, automatically logs out
|
||||
|
||||
* […]
|
||||
|
||||
- Looks like we can preserve session management if we figure out logout
|
||||
- Next would be good to see pseudo code with concrete scenario and sequence diagrams
|
||||
- Pseudo text: [https://github.com/WICG/WebID/blob/main/cookies.md#logout](https://github.com/WICG/WebID/blob/main/cookies.md%23logout)
|
||||
- Prototype is being built
|
||||
- AOB? At IIW?
|
||||
- Understand what third party cookies actually mean - no cookies at all? Partition cookies going away. The way firefox is doing it?
|
||||
* [The State of Identity on the Web](https://medium.com/mattr-global/the-state-of-identity-on-the-web-cffc392bc7ea) Mattr
|
||||
> This article discusses how the success of Open ID Connect shaped the state of identity on the web, how new web standards enable a new model, and describes a bridge between those worlds: [OIDC Credential provider](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/).
|
||||
> This cycle perpetuates the dominance of a few major IdPs and likewise forces users to keep choosing from the same set of options or risk losing access to all of their online accounts. In addition, many of these IdPs have leveraged their role as central intermediaries to increase surveillance and user behavior tracking, not just across their proprietary services, but across a user’s entire web experience.
|
||||
> [...]
|
||||
> [OIDC Credential Provider](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/) allows you to extend OIDC to allow IdPs to issue reusable VCs about the end-user instead of simple identity tokens with limited functionality. It allows end-users to request credentials from an OpenID Provider and manage their own credentials in a [digital wallet](https://learn.mattr.global/concepts/digital-wallets) under their control.
|
||||
* [@kimdhamilton](https://twitter.com/kimdhamilton) · [May 25](https://twitter.com/kimdhamilton/status/1397241823190523904)
|
||||
|
||||
I've read every decentralized identity protocol so you don't have to. They all just read like "nothing to see here, just f- right off" Oh, except for OIDC Credential Provider. Well done to them!
|
||||
|
||||
* [How a combination of Federated identity and Verifiable Credentials can help with Customer onboarding](https://pranavkirtani.medium.com/how-a-combination-of-federated-identity-and-verifiable-credentials-can-help-with-customer-7e6518feb018) Pranav Kirtani
|
||||
|
||||
Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the current methods being used for onboarding.
|
||||
* [OIDC with SIOPv2 and DIF Presentation Exchange](https://vimeo.com/630104529) Sphereon
|
||||
|
||||
* [First Public Review Period for OpenID Connect SIOPV2 and OIDC4VP Specifications Started](https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/) OpenID
|
||||
|
||||
- Implementer’s Drafts public review period: Friday, December 17, 2021 to Monday, January 31, 2022 (45 days)
|
||||
- Implementer’s Drafts vote announcement: Tuesday, January 18, 2022
|
||||
- Implementer’s Drafts voting period: Tuesday, February 1, 2022 to Tuesday, February 8, 2022 *
|
||||
|
||||
* [First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved](https://openid.net/2022/02/08/first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications-approved/) OpenID
|
||||
|
||||
* [Vote for First Implementer’s Drafts of OIDConnect SIOPV2 and OIDC4VP Specifications](https://openid.net/2022/01/18/notice-of-vote-for-first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications/) OpenID
|
||||
|
||||
The official voting period will be between Tuesday, February 1, 2022 and Tuesday, February 8, 2022, following the [45-day review](https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/) of the specifications.
|
||||
* [Differences between SAML, OAuth & OIDC (OpenID Connect)](https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/)
|
||||
> SAML 2.0 - Security Assertion Markup Language
|
||||
>
|
||||
> OAuth 2.0 - Web Authorization Protocol
|
||||
> OpenID Connect 1.0 (OIDC) - Simple identity layer on top of OAuth 2.0
|
||||
|
||||
|
||||
### Assorted
|
||||
- Work within DIF
|
||||
- [Credentials and Claims](https://github.com/decentralized-identity/org/blob/master/Org%2520documents/WG%2520documents/DIF_CC_WG_charter_v1.pdf) working group (explicitly mentions something like "unifying existing formats and protocols" in its charter) <- fast time
|
||||
- Or new WG, draft charter by Balazs: [https://docs.google.com/document/d/18L2-t4_2yrO_xZkwPjMCRcKIDiRGCziNs2X4k093pvo/](https://docs.google.com/document/d/18L2-t4_2yrO_xZkwPjMCRcKIDiRGCziNs2X4k093pvo/)
|
||||
- DIF - presentation exchange?
|
||||
|
||||
Timeline:
|
||||
|
||||
- When is the next Claims and Credentials Group? (who are the chairs? - Martin, Wayne, Daniel McGrogan ) Bi-Weekly -
|
||||
- Work Items within DIF WG can have their own dedicated Calls.
|
||||
- Join DIF: [https://identity.foundation/join/](https://identity.foundation/join/)
|
||||
- Stewardship - , Orie, Brent, Snorre, Stephen? Troy
|
||||
- DIDComm Expert - Sam, Stephen
|
||||
- Presentation Exchange Expert -
|
||||
- Register for the first meeting:(26th April, Monday 1pm ET) [https://forms.gle/SqkymupnYc9tDARm9](https://forms.gle/SqkymupnYc9tDARm9)
|
||||
|
||||
* [VC-HTTP-API discussion (FAQ, vs other APIs, etc)](https://iiw.idcommons.net/13E/_VC-HTTP-API_discussion_-FAQ,_vs_other_APIs,_etc-) by Dmitri Zagidulin
|
||||
|
||||
* [https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/](https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/)
|
||||
|
||||
* [W3C CCG weekly call about VC HTTP APIs](https://iiw.idcommons.net/1P/_9am_PT:_W3C_CCG_weekly_call_about_VC_HTTP_APIs) – W3C CCG
|
||||
|
||||
We discussed[https://github.com/w3c-ccg/vc-http-api](https://github.com/w3c-ccg/vc-http-api)[Address concerns with VC-HTTP-API #190](https://github.com/w3c-ccg/community/issues/190)
|
||||
|
||||
* [[PROPOSED WORK ITEM] Traceability API #191](https://github.com/w3c-ccg/community/issues/191)
|
||||
See also [https://w3c-ccg.github.io/meetings/](https://w3c-ccg.github.io/meetings/)
|
||||
|
||||
@ -0,0 +1,47 @@
|
||||
# MDL
|
||||
|
||||
* [Meet Kantara’s new Executive Director, Kay Chopard](https://www.ubisecure.com/podcast/kay-chopard-kantara/) Lets Talk about Digital Identity
|
||||
> Kay explores why identity is so critical in so many applications; her hope for more promotion of Kantara’s great work and to advance opportunities for collaboration; Kantara’s new mobile drivers licenses (mDLs) work group; Women in Identity and the problem of lack of diversity in standards working groups; and why access and inclusion is one of the biggest challenges facing identity today.
|
||||
* [Verifiable Driver's Licenses and ISO-18013-5 (mDL)](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0105.html) Manu Sporny (Monday, 29 November)
|
||||
> Spruce, MATTR, and Digital Bazaar have collaborated on creating an interoperability test suite for something we're calling the "Verifiable Driver's License" (temporary name):
|
||||
* [The test suite](http://w3id.org/vdl/interop-reports) demonstrates that a few things are possible in addition to what mDL provides:
|
||||
> 1. The mDL data model can be expressed cleanly using W3C Verifiable Credentials
|
||||
* ["Apple launches the first driver’s license and state ID in Wallet with Arizona”](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0231.html) Liam McCarty (Wednesday, 23 March)
|
||||
> It’s sad and frustrating that this isn’t based on verifiable credentials… it appears vendor lock in is going to be hard to prevent.
|
||||
>
|
||||
> For anyone who missed the November coverage about this, here’s a pretty outrageous CNBC article: "[Apple is sticking taxpayers with part of the bill for rollout of tech giant's digital ID card](https://www.cnbc.com/2021/11/14/apple-sticking-taxpayers-with-part-of-the-bill-for-digital-id-rollout.html)”
|
||||
* [Mike Jones shares](https://self-issued.info/?p=2136) that CBOR (Concise Binary Object Representation) is officially a [specification at IETF](https://www.rfc-editor.org/rfc/rfc8943) - woohoo! and it is a key part of [ISO’s mDL standard](https://www.iso.org/committee/45144.html) (date fields must use it).
|
||||
> The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
|
||||
- [The selective disclosure industry landscape, including Verifiable Credentials and ISO Mobile Driver Licenses (mDL)](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-why-selective-disclosure-00) – [Kristina Yasuda](https://twitter.com/kristinayasuda)
|
||||
|
||||
* [Meet Kantara’s new Executive Director, Kay Chopard](https://www.ubisecure.com/podcast/kay-chopard-kantara/) Lets Talk about Digital Identity
|
||||
> Kay explores why identity is so critical in so many applications; her hope for more promotion of Kantara’s great work and to advance opportunities for collaboration; Kantara’s new mobile drivers licenses (mDLs) work group; Women in Identity and the problem of lack of diversity in standards working groups; and why access and inclusion is one of the biggest challenges facing identity today.
|
||||
* [Working Group for Privacy Enhancing Mobile Credentials](https://kantarainitiative.org/introducing-kantaras-working-group-for-privacy-enhancing-mobile-credentials/) Kantara Initiative
|
||||
> Clearly the use of a driver’s license goes well beyond proving eligibility to drive a vehicle. It has become the de-facto standard for proving that you are who you say you are – and are entitled to the product or service requested. An increasing number of states are adopting mobile ID systems to recognise and verify mobile credentials including driver’s licenses (mDL).
|
||||
* [Kantara Releases Report on Identity and Privacy Protection For mobile Driver’s Licenses](https://kantarainitiative.org/kantara-releases-report-on-identity-and-privacy-protection-for-mobile-drivers-licenses/)
|
||||
> The report outlines how to implement mDL systems as Privacy Enhancing Technologies. It provides guidance on protecting people’s individual privacy and the digital identifiers of an individual who carries or uses an mDL.
|
||||
* [Kantara lays out trust-building recommendations for mDLs](https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/)
|
||||
> A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and
|
||||
|
||||
* [Mobile Driver’s Licence (mDL) VS. Self-Sovereign Identity (SSI)](https://inatba.org/identity/mobile-drivers-licence-mdl-self-sovereign-identity-ssi-comparison/) INATBA
|
||||
|
||||
The ISO mDL specification (ISO-compliant Driving License or IDL) is purpose driven, as its name implies, but is said to be specifically intended to:
|
||||
|
||||
- enable verifiers not affiliated with or associated with the issuing authority to gain access to and authenticate the information
|
||||
- allow the holder of the driving license to decide what information to release to a verifier
|
||||
- include the ability to update information frequently, and to authenticate information at a high level of confidence.
|
||||
|
||||
|
||||
* [ISO/IEC 18013-5 vs Self-Sovereign Identity: A proposal for an mDL Verifiable Credential](https://www.procivis.ch/post/iso-iec-18013-5-vs-self-sovereign-identity-a-proposal-for-an-mdl-verifiable-credential) Procivis
|
||||
> in the context of government identity programs we see it as useful to compare them on the following parameters – background, credential data model & trust anchor and transmission protocols.
|
||||
* [Community Project on mDL and VCs](https://newsletter.identosphere.net/i/73037307/where-the-wc-verifiable-credentials-meets-the-iso-mobile-driving-license)
|
||||
|
||||
Next week we are hosting two community calls to collect input for the project On Sept 27th in [Asia morning time](https://www.eventbrite.com/e/where-the-w3c-vcs-meets-the-iso-180135-mdl-apac-time-tickets-425211377677) and on Sept 27th in [US morning time](https://www.eventbrite.com/e/where-the-w3c-vcs-meets-the-iso-180135-mdl-eu-africa-americas-time-tickets-425242470677).
|
||||
* [Kantara lays out trust-building recommendations for mDLs](https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/)
|
||||
|
||||
A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and
|
||||
* [“Decentralised Identity: What’s at Stake?”](https://inatba.org/wp-content/uploads/2020/11/2020-11-INATBA-Decentralised-Identity-001.pdf). ← earlier paper
|
||||
> Looking at the above comparison, It is clear that both approaches strive to maintain user control of their personal data, selective disclosure/data minimization, and cryptographic methods to prove the integrity of identity claims. The differences are: first in their reliance (mDL) or independence (SSI) from issuer involvement in verification interactions, and second in their cryptographic approach, where the mDL relies on externally provided cryptographic tools while SSI builds on holder controlled private keys
|
||||
* [An Identity Wallet Bill of Rights - Starting With the Mobile Driver License](https://blog.spruceid.com/an-identity-wallet-bill-of-rights/) Spruce Systems
|
||||
|
||||
Spruce’s continued mission is to let users control their data across the web, whether it’s web2, web3, or beyond. This also applies to credentials issued by existing entities, such as the Mobile Driver License (mDL) issued by motor vehicle authorities across the world.
|
||||
@ -1,423 +0,0 @@
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
# Credential Exchange
|
||||
|
||||
|
||||
* [Figuring out Verifiable Credentials Exchange - combining Bloom, Aires Protocols, Presentation Exchange into a unified - Killer Whale Jello Salad](https://iiw.idcommons.net/22H/_Figuring_out_Verifiable_Credentials_Exchange_-_combining_Bloom,_Aires_Protocols,_Presentation_Exchange_into_a_unified_-_Killer_Whale_Jello_Salad) by Kaliya Young, Orie Steele, Drummond , Kyle et al
|
||||
|
||||
|
||||
- [https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit#slide=id.p](https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit%23slide%3Did.p)
|
||||
|
||||
ReCap & Summary
|
||||
|
||||
- Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
|
||||
- Goal to create a bridge between
|
||||
- the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
|
||||
- Aries protocols run on top of DIDComm
|
||||
- If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
|
||||
- Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
|
||||
- So can be tested with next SVIP - testing.
|
||||
- Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
|
||||
- Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
|
||||
- Potentially quickly spinning up a working group at DIF - Decision was to nest within the Credentials and Claims group at DIF
|
||||
|
||||
Result:
|
||||
|
||||
* [https://identity.foundation/arewewaciyet/](https://identity.foundation/arewewaciyet/)
|
||||
|
||||
|
||||
* [BBS+ Credential Exchange in Hyperledger Aries](https://iiw.idcommons.net/11E/_BBS%252B_Credential_Exchange_in_Hyperledger_Aries)
|
||||
|
||||
* [https://iiw.animo.id](https://iiw.animo.id)
|
||||
|
||||
* [Credentials Exchange - figuring it out - (Jello Bowl Death Match?)](https://iiw.idcommons.net/12F/_Credentials_Exchange_-_figuring_it_out_-_(Jello_Bowl_Death_Match%253F)_%25E2%2580%2593)
|
||||
|
||||
DIDComm, Verifiable Credential Exchange, Aries Protocol, Bloom Protocol, Presentation Exchange ([Slides](https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit%23slide%3Did.p)
|
||||
|
||||
The ultimate goal is to get to a clear exchange protocols.
|
||||
|
||||
Also to have a paper similar to this one that outlines the choice landscape that is and points to a convergence point - [https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf)
|
||||
|
||||
Good Health Pass is literally right now trying to figure this out and will “pick” solutions it needs to get implementations working in the next 30-90 days and point the whole industry in one direction.
|
||||
|
||||
We started out with this framework of understanding
|
||||
|
||||
Contextualizing VC Exchange in Layers
|
||||
|
||||
Verifiable Credentials (VC or VCs) is one of the key standardized components of decentralized identity. [The VCs Data Model](https://www.w3.org/TR/vc-data-model/), defined at the W3C, is a universal data format that lets any entity express anything about another entity. It provides a common mechanism for the interoperable implementation of digital credentials that are cryptographically secure, tamper-evident, privacy-respecting, and machine-verifiable.
|
||||
|
||||
There clarity emerging on standards that are interoperable with one another for the VC format.
|
||||
|
||||
There is less clarity on the Exchange mechanisms.
|
||||
|
||||
One way that has been proposed to look at the exchange options available is to see them in different layers.
|
||||
|
||||
* [...]
|
||||
|
||||
* [Aries RFC 0453 - credential issuance protocol using DIDComm V1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2)
|
||||
|
||||
* [Aries RFC 0454 - Present Proof protocol V2 using DIDCommV1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0454-present-proof-v2)
|
||||
|
||||
DIDComm v2
|
||||
|
||||
Work Item within DIF right now - envelope format with some other opinions we may or may want. Daniel Hardman gave vision - of parts that are done - leaving behind parts not done.
|
||||
|
||||
- DIDCom V2 Envelops JWEs (a standard that exists)
|
||||
- Aries RFCs for payloads that go in JWE envelopes.
|
||||
- Send envelopes over HTTP as a starting point
|
||||
|
||||
* [...]
|
||||
|
||||
CHAPI
|
||||
|
||||
The Credential Handler API or CHAPI is currently a draft community group report developed by/under the Credentials Community Group at the W3C. At the heart of this model is a credential repository which is a Web application that can handle credential requests and credential storage on behalf of the user/holder. The API Is designed to support the transmission of credentials between a web based issuer and a holder with a cloud wallet (credential repository) that is visible in the same browser but in a different tab. It creates a “dumb pipe” between the two tabs in the holder’s browser and permits the transmition of the credential effectively from one tab to another.
|
||||
|
||||
* [...]
|
||||
|
||||
VC-HTTP-API (VHA)
|
||||
|
||||
The VC HTTP is a RESTful API specification (conforming with the [OpenAPI](https://swagger.io/specification/) [3.0 Specification](https://swagger.io/specification/) for constructing and verifying objects which conform to the Verifiable Credential Data Model specification.
|
||||
|
||||
A bit more about the OpenAPI 3.0 specification itself:
|
||||
|
||||
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
|
||||
|
||||
This API is versioned in conformance with the [Semantic Versioning 2.0 specification](https://semver.org/) to prevent breaking changes between minor versions, and to allow for reliable testing and integration of implementations of this API within enterprise environments. This API provides a standard set of interfaces by which interoperability may be tested and verified by various parties who leverage Verifiable Credentials (VCs).
|
||||
|
||||
This slide, from a slide deck presentation by Manu Sporny to the W3C Credentials Community Group on 20 April 2021, explains the relationship of the VC-HTTP-API to CHAPI:
|
||||
|
||||
* [...]
|
||||
|
||||
WACI
|
||||
|
||||
There are interactions between a wallet and relying party that require passing information between the two. WACI provides a standard for these interactions.
|
||||
|
||||
* [https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0/#status-of-this-document](https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0/%23status-of-this-document)
|
||||
|
||||
WACI bound to JWT - signed. Could be JWE technically (would have to know the other parties DID and Keys - only optionally required here).
|
||||
|
||||
Fully supports credential manifest and presentation exchange.
|
||||
|
||||
Could be bound to DIDComm
|
||||
|
||||
Message Format
|
||||
|
||||
Presentation Exchange defined in DIF
|
||||
|
||||
Presentation Exchange is a protocol to support the interaction between holders and verifiers. It supports them being able to express what combination of credential the verifier wants or needs.
|
||||
|
||||
Credential Manifest as defined in DIF
|
||||
|
||||
Asking for a presentation
|
||||
|
||||
And asking proof to enable issuing a credential.
|
||||
|
||||
Indy Proof Request
|
||||
|
||||
Aries Exchange Protocol
|
||||
|
||||
Define the messages that go back and forth between
|
||||
|
||||
Issuer and holder (4 messages)
|
||||
|
||||
Holder and Verifier (3 messages)
|
||||
|
||||
Different formats (types of credentials) are different attachments in those messages.
|
||||
|
||||
DIDComm v1, there is AIP v1 and AIP v2 :)
|
||||
|
||||
Where does it go?
|
||||
|
||||
OIDC-SOIP
|
||||
|
||||
Self-Issued OpenID Connect Provider or OIDC-SOIP was created to take advantage of the fact that there are several 100,000 implementations of OpenID Connect on todays web. This method of exchange verifiable credentials leverages that infrastructure with a few small changes to support OpenID enabled sites to be able to accept verifiable credentials. Holders have wallets or agents that they use to interact with a system. The protocols to do this are being worked on jointly by the OpenID Foundation and Decentralized Identity Foundation.
|
||||
|
||||
Recommended Medium articles about OpenID, VCs, DIDs, and decentralized identity by Nader Helmy at MATTR:
|
||||
|
||||
1. Dec 15, 2000: [https://medium.com/mattr-global/introducing-oidc-credential-provider-7845391a9881](https://medium.com/mattr-global/introducing-oidc-credential-provider-7845391a9881)
|
||||
2. March 14, 2021: [https://medium.com/mattr-global/the-state-of-identity-on-the-web-cffc392bc7ea](https://medium.com/mattr-global/the-state-of-identity-on-the-web-cffc392bc7ea)
|
||||
|
||||
Current MATTR spec for OpenID Credential Exchange: [https://mattrglobal.github.io/oidc-client-bound-assertions-spec/](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/)
|
||||
|
||||
Raise up to the connect working group
|
||||
|
||||
More on the presentation side of things.
|
||||
|
||||
OpenID_Credential.
|
||||
|
||||
RP wallet holder.
|
||||
|
||||
Self-Issued OpenID Connect Provider
|
||||
|
||||
EXTENSION for OPs to Issue Verifiable Credentials.
|
||||
|
||||
Stand up your own openID Connect provider to stand up a wallet.
|
||||
|
||||
If you are doing a custodial system.
|
||||
|
||||
Google can be your OP and your wallet.
|
||||
|
||||
Progressive web application - where it is the OP itself. That web-app is able to be your wallet.
|
||||
|
||||
Original version of SIOP getting ID Token for a DID.
|
||||
|
||||
Future - heading…
|
||||
|
||||
Allow OIDC to support issuance of
|
||||
|
||||
Allow OIDC to support presentation of VCs.
|
||||
|
||||
Aggregated Claim Usage - determine how VC flow to hold from OP to RP.
|
||||
|
||||
OpenID Foundation has been pulling things apart.
|
||||
|
||||
Separate spec called portable identifiers - could apply to SSI. (JWK thumbprints).
|
||||
|
||||
Chat about Aries. During issuance there is an implied assumption already authenticated - some sort of authentication
|
||||
|
||||
Way DHS Demo works - DID Auth request - VC presentation exchange.
|
||||
|
||||
DIDSIOP is a dead term - multiple extensions in openiD foundation - some will be relevent.
|
||||
|
||||
Issuance and authentication are two steps in some places and in other places they are one step.
|
||||
|
||||
Looking for a solution for I am a holder A - holder B - present credentials to drummond. Go to his website - start a flow from QR code - to initiate presentation flow. Not helpful to bring in concept of credential issuers.
|
||||
|
||||
Presentations of Credentials.
|
||||
|
||||
I don’t have an authenticated session - want to get to a presentation of a VC.
|
||||
|
||||
There really are entirely different protocols - how do you get it into your wallet. How do you authenticate to the issuer to assure rightful subject/holder - multiple ways to do that.
|
||||
|
||||
Entirely different protocols for issuance and presentation - can be different.
|
||||
|
||||
Are they trying to reach the same place.
|
||||
|
||||
Yes they are trying to do both.
|
||||
|
||||
Mutual Authentication - breaks with many of the protocols. It is a key feature of SSI.
|
||||
|
||||
Drummond - need separate issuance and verification.
|
||||
|
||||
Having a way to bind protocols into a single session - single Aires connection.
|
||||
|
||||
Sep
|
||||
|
||||
Daniel - learned something in ories comment - verifier work flow. Credential exchange is used - always issuance - never means proving.
|
||||
|
||||
We could collapse complexity out of Aires - aries of messages instead of API calls - should be described as message exchanges (thumbs up from Orie).
|
||||
|
||||
Brent - good conversation.
|
||||
|
||||
ORIE
|
||||
|
||||
We are on a whale watching expedition - largest great white shark - try and complete with largest killer whale. Trying to capture the presentation exchange
|
||||
|
||||
OpenIDConnect - is all of the largest IdP
|
||||
|
||||
Gravity Well - connected largest industry players - regardless of openID
|
||||
|
||||
Hunting helpless little seals.
|
||||
|
||||
Outside of OpenID Connect the next biggest “animal” is Aries protocols.
|
||||
|
||||
What if we had one or two things that are eating all of the seals. Is there another one?
|
||||
|
||||
Kyle - deployment architectures is what has made this so hard.
|
||||
|
||||
Presentation in offline - DIDComm only.
|
||||
|
||||
Reasonable assumption one online one not - DIDComm with OIDC.
|
||||
|
||||
Server to server - look in completely different scenario.
|
||||
|
||||
Quite like the idea of combining different things.
|
||||
|
||||
DIDComm as authentication mechanism - pre-issuance - from an OIDC issuer.
|
||||
|
||||
How do we combine things together to decide when they fit in different deployment.
|
||||
|
||||
FIDO?
|
||||
|
||||
W3C Data Model - do they care?
|
||||
|
||||
Competing things:
|
||||
|
||||
mDL ISO 18013-5
|
||||
|
||||
MRTD -
|
||||
|
||||
Bloom Spec + Aries RFC - tried to describe without any baggage.
|
||||
|
||||
Simplified - message based - description of steps challenging getting proofs back.
|
||||
|
||||
Minor upgrade from Aries.
|
||||
|
||||
Implemented with
|
||||
|
||||
Other key thoughts: OpenID only usable by institutions.
|
||||
|
||||
Individuals asking individuals for proof - no implementations individuals have software in their control proof over
|
||||
|
||||
Combining things.
|
||||
|
||||
Things that limit aries
|
||||
|
||||
* [More Killer Whale Jello Salad…figuring out how credential exchange can harmonize.](https://iiw.idcommons.net/24B/_More_Killer_Whale_Jello_Salad...figuring_out_how_credential_exchange_can_harmonize.) by Kaliya Young et al.
|
||||
|
||||
ReCap & Summary
|
||||
|
||||
- Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
|
||||
- Goal to create a bridge between
|
||||
- the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
|
||||
- Aries protocols run on top of DIDComm
|
||||
- If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
|
||||
- Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
|
||||
- So can be tested with next SVIP - testing.
|
||||
- Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
|
||||
- Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
|
||||
- Potentially quickly spinning up a working group at DIF - Decision was to nest within the Credentials and Claims group at DIF
|
||||
|
||||
Agenda Creation
|
||||
|
||||
Things on the Path:
|
||||
|
||||
- Scope/Goals:
|
||||
- Specification good and complete
|
||||
-
|
||||
- BBS+ enabled attestation that transit across issuer, holder, verifier using the rails (paved path) that are envisioned here.
|
||||
- Maximal adoption as soon as possible,
|
||||
- Proceed forward in a way - that doesn’t require us to abandon some aspect of what we are doing - start with simpler form to get to bigger. Path can be made wider in future.
|
||||
- System architecture diagram that articulates how it all fits together - next step.
|
||||
- Do not re-invent things that already exist.
|
||||
- Test Suite - Test conformance vs. a Specification <- end goal interoperable implementation
|
||||
- A matrix Testing N-N testing - plugfest.
|
||||
- Be nice pick fast resolving DID methods for testing
|
||||
- Implementation Guide - maybe by: Documentation Corps in DIF
|
||||
- Test are about SHOWING the protocols work - not that the DID resolution works
|
||||
- Define the Rails:
|
||||
- Government issues the credential using software of their choice - did anchored in some did utility - citizen able to use a wallet of their choice - that they hold it in - business using a different software (and different ledger for their public did) all able to do this making their own choices. The reason they can is because of those rails - claim we can do this to a great extent - what we can not do right now across the linked-data signature Aries Ecosystem. Show how we can do what you just described across ecosystems. (Mediation is important - how do we do mediation on these rails).
|
||||
- System creating presentation is - web wallet, backend system or mobile app.
|
||||
- We need to handle working with registered web wallets - and also be able to formulate a payload for mobile (QR code) both of these paths need to be speced out to cover both communities.
|
||||
- We need as many Verifiers as possible (to devalue information on the dark web - with
|
||||
- Only HTTP Transports
|
||||
- Verifier - Holder - Issuer
|
||||
|
||||
Verifier - is a web accessible verifier.
|
||||
|
||||
Holder - app/mobile wallet, Browser wallet , backend service wallet (supply chain)
|
||||
|
||||
Issuer - is a web accessible verifier.
|
||||
|
||||
Things to Paint out of Interoperability Picture / Path Narrowing:
|
||||
|
||||
- Non-HTTP Transports (however, let's leave room for non-HTTP transports for future iterations)
|
||||
- Don’t do negotiation in presentation exchange
|
||||
- Request -> Presentation -> Fail -> Error
|
||||
- Lots of way to specify requirements inside presentation exchange - features we decide we are not going to use.
|
||||
- Credential formats will comply with the W3C VC Data Model
|
||||
- Support for VC-JWT and LD Proof with example of BBS+ (BLS12381 G2) and ES256
|
||||
- No revocation (not ready enough yet) [revocation list 2020 does exist]
|
||||
- Holder refresh is out of scope [there is some work going on on this]
|
||||
- Issuer/verifier mobile app
|
||||
|
||||
Targets for path widening later
|
||||
|
||||
- Revocation
|
||||
- Holder Refresh
|
||||
- Credential Issuance
|
||||
|
||||
What work will go where?
|
||||
|
||||
- Work within DIF
|
||||
- [Credentials and Claims](https://github.com/decentralized-identity/org/blob/master/Org%2520documents/WG%2520documents/DIF_CC_WG_charter_v1.pdf) working group (explicitly mentions something like "unifying existing formats and protocols" in its charter) <- fast time
|
||||
- Or new WG, draft charter by Balazs: [https://docs.google.com/document/d/18L2-t4_2yrO_xZkwPjMCRcKIDiRGCziNs2X4k093pvo/](https://docs.google.com/document/d/18L2-t4_2yrO_xZkwPjMCRcKIDiRGCziNs2X4k093pvo/)
|
||||
- DIF - presentation exchange?
|
||||
|
||||
Timeline:
|
||||
|
||||
- When is the next Claims and Credentials Group? (who are the chairs? - Martin, Wayne, Daniel McGrogan ) Bi-Weekly -
|
||||
- Work Items within DIF WG can have their own dedicated Calls.
|
||||
- Join DIF: [https://identity.foundation/join/](https://identity.foundation/join/)
|
||||
- Stewardship - , Orie, Brent, Snorre, Stephen? Troy
|
||||
- DIDComm Expert - Sam, Stephen
|
||||
- Presentation Exchange Expert -
|
||||
- Register for the first meeting:(26th April, Monday 1pm ET) [https://forms.gle/SqkymupnYc9tDARm9](https://forms.gle/SqkymupnYc9tDARm9)
|
||||
|
||||
When do we want it done?
|
||||
|
||||
Good Health Pass has tremendous pressure!
|
||||
|
||||
When do we need what by?
|
||||
|
||||
Feedback into this group from Good Health Pass.
|
||||
|
||||
May 1: GHP Drafting Groups First Drafts Due -
|
||||
June 1 GHP Interoperability Blueprint Recommendations Spec complete
|
||||
|
||||
- 30 day vision
|
||||
- 90 day vision <- would be ideal to have something that can be tested against for this timeframe.
|
||||
- 180 day vision
|
||||
|
||||
July 1 Test Complete
|
||||
|
||||
August 1 - 10+ Implementations / Vendors passing VP Exchange Interop Tests.
|
||||
|
||||
October 1 - Cross Wallet Interop Exchange Tests.
|
||||
|
||||
Share with DIF Interoperability Working Group
|
||||
|
||||
Success Criteria:
|
||||
|
||||
- Interop Testing Outcome
|
||||
- Artifacts Produced
|
||||
- Test Artifacts to TEST <- effort time and energy
|
||||
|
||||
Milestones:
|
||||
|
||||
Daniel Hardman wrote this before IIW in the DIF slack and many people +1 it.
|
||||
|
||||
this was ideated by Daniel before the last meeting, Balazs just copied it here for safekeeping.
|
||||
|
||||
* [Daniel Hardman](https://app.slack.com/team/U01UWQTJMCZ) [18 hours ago](https://difdn.slack.com/archives/CRMKSUE8M/p1619112488145600?thread_ts%3D1619048996.142500%26cid%3DCRMKSUE8M)
|
||||
|
||||
I see this as being a layered spec:
|
||||
|
||||
Layer 1 = plaintext JSON payloads, presented in sequence, with possible error conditions. Understanding the spec at this level requires nothing except knowledge of JSON and the general problem domain of VCs. No DIDComm, no HL anything, no dependencies anywhere.
|
||||
|
||||
Layer 2 = Security. How to wrap layer 1 such that two parties can exchange the payloads and achieve the trust they need in the process. Here, I see a forked path: use TLS (in which case security is really simple, but is transport dependent), or use DIDComm (in which case you use the JWE wrapper that DIDComm is standardizing, based on keys in a DID doc -- more complex but more flexible). The key thing about Layer 2 is that once it's stripped away (e.g., by an adapter), the payloads exchanged at layer 1 are identical and interoperable.
|
||||
|
||||
Layer 3: routing. This is for delivering payloads via intermediaries. It is not needed by HTTP that's direct point-to-point. If you add this layer, you introduce more DIDComm-isms but gain extra flexibility as well.
|
||||
|
||||
If you like this framing, then I see a spec where layer 1 is presented very quickly and easily; it should be ultra simple and easy to understand by anyone who knows JSON. No mention of any dependencies anywhere.
|
||||
|
||||
This would be followed by an explanation of why additional layers could be added, and then a presentation of a 2-forked road, where one is pure HTTP (TLS for security, no routing), and one is DIDComm (DID docs for security, transport-independent routing). Both use the same layer 1.
|
||||
|
||||
Having presented the two forks at a high level, I would then imagine a page of text describing how the HTTP fork would work (HTTP status codes, adaptation for web sockets vs. web hooks, etc).
|
||||
|
||||
Then I would imagine a page describing how the DIDComm fork would work -- but instead of hyperlinking to DIDComm auxiliary material, it would be a page or two of copy-pasted material that would allow DIDComm compatibility without consuming any other docs.
|
||||
|
||||
The upshot would be a single doc that:
|
||||
|
||||
A) describes a simple exchange of messages that lets credential-based proof be requested and presented
|
||||
|
||||
B) Structures the messages in a way that's compatible with DIDComm, without requiring anybody outside the DIDComm circle to know that.
|
||||
|
||||
C) Explains how the protocol could run over a web service.
|
||||
|
||||
D) Explains how the protocol could run over DIDComm -- but in a simplified, self-contained doc rather than with dependencies.
|
||||
|
||||
E) Explains the tradeoffs of the pure HTTP vs. DIDComm approaches.
|
||||
|
||||
* [VC-HTTP-API discussion (FAQ, vs other APIs, etc)](https://iiw.idcommons.net/13E/_VC-HTTP-API_discussion_-FAQ,_vs_other_APIs,_etc-) by Dmitri Zagidulin
|
||||
|
||||
* [https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/](https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/)
|
||||
|
||||
* [W3C CCG weekly call about VC HTTP APIs](https://iiw.idcommons.net/1P/_9am_PT:_W3C_CCG_weekly_call_about_VC_HTTP_APIs) – W3C CCG
|
||||
|
||||
We discussed[https://github.com/w3c-ccg/vc-http-api](https://github.com/w3c-ccg/vc-http-api)[Address concerns with VC-HTTP-API #190](https://github.com/w3c-ccg/community/issues/190)
|
||||
|
||||
* [[PROPOSED WORK ITEM] Traceability API #191](https://github.com/w3c-ccg/community/issues/191)
|
||||
See also [https://w3c-ccg.github.io/meetings/](https://w3c-ccg.github.io/meetings/)
|
||||
@ -58,52 +58,6 @@ To recap:
|
||||
|
||||
On their own independent schedules, all browsers have either broken or have plans to break state sharing via cross-site iframes to limit user tracking - arguably making the Session Management approach unusable.
|
||||
|
||||
* [Browser APIs to enable OpenID Session Management and Privacy](https://iiw.idcommons.net/13L/_Browser_APIs_to_enable_OpenID_Session_Management_and_Privacy) by Sam Goto
|
||||
|
||||
How does logout in OIDC happen?
|
||||
|
||||
- Classification problem - browsers do not know it is a logout now
|
||||
- Easiest way
|
||||
- Browser asks for a user consent
|
||||
- Hard from a permission implementation perspective
|
||||
- Tim: No issues with this idea
|
||||
- If user logged into several OPs, user will not look to all the ones they log out from
|
||||
- Option2
|
||||
- Browser classifies signing-in event
|
||||
- On log out does not prompt the user and IdP has no incentives to lie
|
||||
- RPs get to determine if they want to log the user out or not
|
||||
- Whether you can swap generic frame with fenced frame, frame can see it’s own cookies
|
||||
- May not be able to pass any parameters that you need to pass; no link decoration for framed frame
|
||||
- Subdomains also considered, but not well thought out
|
||||
- Logout URL - other option to add, but more work for RP: Resource metadata. Specification - not much adoption. It just feels like a place where RP metadata could be declared which could be useful in this context of the RP defining its metadata (e.g. what IDP it uses
|
||||
- [draft-jones-oauth-resource-metadata-01 - OAuth 2.0 Protected Resource Metadata (ietf.org)](https://tools.ietf.org/html/draft-jones-oauth-resource-metadata-01)
|
||||
- On digression: [https://cloudidentity.com/blog/wp-content/uploads/2013/01/3252.image_5F00_04277494.png](https://cloudidentity.com/blog/wp-content/uploads/2013/01/3252.image_5F00_04277494.png)
|
||||
- Messy real-life situation - sign in to AAD with OIDC and WS-fed; register something at sign-in. From a user, same account, does not matter which protocol is used
|
||||
- What needs more to be discussed what log out means to the user
|
||||
- User does not understand when they log out from office, they also log out from Azure
|
||||
- Also a developer choice
|
||||
- Relevant one, but not much browsers can do about
|
||||
- If a bigger picture is browser wants to be in the middle, browser can do something in this area too.
|
||||
- Ugly part of logout - mechanisms to allow the range of services
|
||||
- IdP does not need to send back list of all RPs user is logging out from
|
||||
- Idea not entirely off for IdP to tell a browser from there it wants to log user out from
|
||||
- Browser have confident of the user intent
|
||||
- Prompt the user for the intent - never a good idea
|
||||
- Logout API that community can control a behaviour of
|
||||
- You call it, browser logs it, and tell where the user left of
|
||||
- Browser observes the login - passively. Heuristics - what if the browser has not seen it..
|
||||
- some of this is already starting to show up in chrome canarie
|
||||
- [https://chromium-review.googlesource.com/c/chromium/src/+/2837551](https://chromium-review.googlesource.com/c/chromium/src/%2B/2837551)
|
||||
- If domain name ETLD of the issuer is the same as IdP, automatically logs out
|
||||
|
||||
* […]
|
||||
|
||||
- Looks like we can preserve session management if we figure out logout
|
||||
- Next would be good to see pseudo code with concrete scenario and sequence diagrams
|
||||
- Pseudo text: [https://github.com/WICG/WebID/blob/main/cookies.md#logout](https://github.com/WICG/WebID/blob/main/cookies.md%23logout)
|
||||
- Prototype is being built
|
||||
- AOB? At IIW?
|
||||
- Understand what third party cookies actually mean - no cookies at all? Partition cookies going away. The way firefox is doing it?
|
||||
|
||||
* [TMI BFF: OAuth Token Mediating and session Information Backend For Frontend](https://iiw.idcommons.net/23B/_TMI_BFF:_OAuth_Token_Mediating_and_session_Information_Backend_For_Frontend) by Vittorio Bertocci & Brian Campbell (but mostly Vittorio)
|
||||
|
||||
@ -128,11 +82,8 @@ TMI BFF
|
||||
* [...]
|
||||
|
||||
What is the scope - acquiring a token for direct API access, not necessarily prescriptive for BFF architectures which put all API interactions through BFF. (DW) raised issue that simply converting OAuth calls in a remote party to local API calls protected by a cookie disables some security protections provided by OAuth tokens (XSRF), so some sort of BFF best practices may be needed to prevent footguns.
|
||||
* [The State of Identity on the Web](https://medium.com/mattr-global/the-state-of-identity-on-the-web-cffc392bc7ea) Mattr
|
||||
> This article discusses how the success of Open ID Connect shaped the state of identity on the web, how new web standards enable a new model, and describes a bridge between those worlds: [OIDC Credential provider](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/).
|
||||
> This cycle perpetuates the dominance of a few major IdPs and likewise forces users to keep choosing from the same set of options or risk losing access to all of their online accounts. In addition, many of these IdPs have leveraged their role as central intermediaries to increase surveillance and user behavior tracking, not just across their proprietary services, but across a user’s entire web experience.
|
||||
> [...]
|
||||
> [OIDC Credential Provider](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/) allows you to extend OIDC to allow IdPs to issue reusable VCs about the end-user instead of simple identity tokens with limited functionality. It allows end-users to request credentials from an OpenID Provider and manage their own credentials in a [digital wallet](https://learn.mattr.global/concepts/digital-wallets) under their control.
|
||||
|
||||
|
||||
|
||||
* OpenID: [Public Review Period for Proposed Final OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core Specification](https://openid.net/2021/06/07/public-review-period-for-proposed-final-openid-connect-client-initiated-backchannel-authentication-ciba-core-specification/)
|
||||
|
||||
|
||||
@ -7,6 +7,10 @@ published: false
|
||||
* [KERI Q&A basic introduction](https://iiw.idcommons.net/3K/_KERI_Q%2526A_basic_introduction) by Henk van Cann
|
||||
|
||||
This the link to the 20 minute introductory presentation in pdf:
|
||||
- [decentralized-identity/keriox](https://github.com/decentralized-identity/keriox) github - Rust Implementation of the KERI Core Library
|
||||
|
||||
* [Rust KERI implementation](https://github.com/decentralized-identity/keriox/) Jolocom
|
||||
> We at Jolocom strongly believe that DIDComm is a crucial infrastructure element for the broader and future-proof SSI stack, and current work on [DIDComm v2](https://identity.foundation/didcomm-messaging/spec/) includes Jolocom’s implementation of the specification with authcrypt (authenticated encrypted) and most of the low level of the protocol.
|
||||
|
||||
* [https://blockchainbird.org/downloads/KERI-QA-introduction.pdf](https://blockchainbird.org/downloads/KERI-QA-introduction.pdf)
|
||||
|
||||
|
||||
@ -13,35 +13,13 @@ published: false
|
||||
|
||||
* [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.
|
||||
## OpenID Connect
|
||||
* [OpenID Connect Presentation at IIW XXXII](https://self-issued.info/?p%3D2167)
|
||||
- [OpenID Connect](https://openid.net/connect/)
|
||||
- [Frequently Asked Questions](https://openid.net/connect/faq/)
|
||||
- [Working Group Mailing List](https://lists.openid.net/mailman/listinfo/openid-specs-ab)
|
||||
- [OpenID Certification Program](https://openid.net/certification/)
|
||||
- [Certified OpenID Connect Implementations Featured for Developers](https://openid.net/developers/certified/)
|
||||
|
||||
## 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.
|
||||
* [Universal Resolver Driver Policy Discussion](https://iiw.idcommons.net/21P/_Universal_Resolver_Driver_Policy_Discussion) by Bernhard Fuchs, Markus Sabadello
|
||||
|
||||
Currently, instances of the Universal Resolver is hosted by DIF, IBM, and other companies. Danube Tech has been maintaining the project.
|
||||
|
||||
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)
|
||||
|
||||
We have some ongoing questions on policies for Universal Resolver drivers.
|
||||
|
||||
Proposal: We should require contact data for maintainers of drivers (could be email address or any other type of contact data).
|
||||
|
||||
Another challenge is that there may be multiple projects claiming the same DID method name. How to decide which DID method driver to include in the Universal Resolver?
|
||||
|
||||
Proposal: Driver implementers must get their DID method registered first in the W3C DID method registry, then they can contribute a Universal Resolver driver (this avoids ambiguities)
|
||||
|
||||
DID test suite: [https://github.com/w3c/did-test-suite](https://github.com/w3c/did-test-suite)
|
||||
|
||||
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?
|
||||
* [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
|
||||
|
||||
@ -84,11 +62,6 @@ Aaron Parecki - Mr. OAuth has a new course out on Udemy
|
||||
|
||||
> 3.5 hours of video content, quizzes, as well as interactive exercises with a guided learning tool to get you quickly up to speed on OAuth, OpenID Connect, PKCE, best practices, and tips for protecting APIs with OAuth.
|
||||
|
||||
### Universal Resolver supports ION DID Method
|
||||
|
||||
* [@dialtone4web](https://twitter.com/dialtone4web) shares: *"ION based[@DecentralizedID](https://twitter.com/DecentralizedID) identifiers can now be resolved by the UniversalResolver. #v0.8.1 #ownyouridentity"*
|
||||
|
||||
* [Adds support for resolving ION DIDs #154](https://github.com/decentralized-identity/universal-resolver/pull/154)
|
||||
|
||||
### Grant Negotiation and Authorization Protocol (GNAP)
|
||||
|
||||
@ -100,8 +73,6 @@ Aaron Parecki - Mr. OAuth has a new course out on Udemy
|
||||
* [Filling in the GNAP](https://medium.com/@justinsecurity/filling-in-the-gnap-a032453eaf8c)
|
||||
> Justin Richer identity protocol writer and implementer extraordinaire has a very excellent post explaining the new GNAP and all the things that lead to it, including OAuth, OpenID, TxAuth, OAuth3, and OAuth.XYZ. This protocol is a big deal and will be important. It’s just beginning the journey through IETF (Internet Engineering Task Force) the main standards body of the internet.
|
||||
|
||||
* [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.
|
||||
|
||||
* [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)
|
||||
@ -134,3 +105,5 @@ Available on the Open University’s OpenLearn Create platform and is licensed u
|
||||
* [Getting Started with Self-Sovereign Identity](https://www.edx.org/course/getting-started-with-self-sovereign-identity) Kaliya & Lucy via Linux Foundation and EdX
|
||||
|
||||
Gain a solid foundation on self-sovereign identity (SSI) with a 360 degree overview of its evolutionary journey, key concepts, standards, technological building blocks, use cases, real-world examples and implementation considerations.
|
||||
* [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.
|
||||
|
||||
@ -4,26 +4,9 @@ published: false
|
||||
|
||||
# Standards Bodies
|
||||
|
||||
* [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.
|
||||
|
||||
* [Decentralized Profiles group Nov 25th call](https://blog.ceramic.network/dprofiles-call-3/)
|
||||
Every 6 weeks the at Ceramic meets
|
||||
* [Ethereum OASIS Receives $100K for Baseline Protocol Projects](https://www.oasis-open.org/2021/03/10/ethereum-oasis-receives-100k-incentive-funding-for-baseline-protocol-projects/)
|
||||
|
||||
Today, the
|
||||
[Baseline Protocol](https://www.baseline-protocol.org/), part of the Ethereum OASIS Open Project and in partnership with
|
||||
[Open Source Collective](http://opencollective.com/opensource), announced that it has received a grant of $100,000 from the
|
||||
[Ethereum Foundation](https://ethereum.foundation/) to be used for the purpose of encouraging and accelerating baseline protocol R&D and enablement efforts. This comes on the first anniversary of the community’s formation.
|
||||
* [DIF SDS/CS WG: CS Refactoring Proposal 0.2](https://hyperonomy.com/2021/03/28/cs-refactoring-proposal/) Hyperonomy
|
||||
|
||||
1. Latest Version of the Proposal (0.2 – March 24, 2021)
|
||||
2. Agent-Hub-EDV Architecture Reference Model (AHE-ARM) 0.1
|
||||
3. Transcription of Selected Parts of the DIF SDS/CS March 11, 2021 Zoom Call
|
||||
4. OSI Stack Proposal for Confidential Storage Specification
|
||||
|
||||
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. I also present a high-level roadmap (simple ordering) for how the WG might proceed if this refactoring is accepted (or at least, if the first part/first new specification is accepted).
|
||||
|
||||
* [Digital Identity in response to COVID-19: DGX Digital Identity Working Group](https://www.tech.gov.sg/files/media/corporate-publications/FY2021/dgx_2021_digital_identity_in_response_to_covid-19.pdf)
|
||||
* [Digital Identity Attestation Roundup - Open Source Security Foundation](https://openssf.org/blog/2021/01/27/digital-identity-attestation-roundup/%23)
|
||||
|
||||
@ -58,9 +41,12 @@ There has been an explosion of interest in using NFT for identity, along with ex
|
||||
|
||||
((Evin seems really cool -kaliya))
|
||||
|
||||
Past Working Group Calls of Interest
|
||||
|
||||
A couple weeks ago Amber Case came and spoke about “[Calm Technology](https://www.youtube.com/watch?v%3DNgyfa4_NuPI)” at the TOIP Human Experience Working Group ([HXWG](https://wiki.trustoverip.org/display/HOME/Human%2BExperience%2BWorking%2BGroup)
|
||||
|
||||
|
||||
* [DIF Steering Committee Election Results 2022](https://blog.identity.foundation/sc-election-2022-results/)
|
||||
|
||||
SC Election results: DIF welcomes new SC members Sam Curren, Daniel Buchner, Karyl Fowler, Rouven Heck, Markus Sabadello & Kaliya Young!
|
||||
|
||||
Michale Herman [is excited](https://twitter.com/mwherman2000/status/1511550968617263114) about the new #VCA (Verifiable Credential Authorization) using the new #VCTPS (Secure Verifiable Credential Transport Protocol) over #DIDCOMM
|
||||
|
||||
@ -109,30 +95,5 @@ The Chain Agnostic Standards Alliance (CASA) is a collection of working groups d
|
||||
|
||||
* [Secure Data Storage](https://identity.foundation/working-groups/secure-data-storage.html)
|
||||
|
||||
- [User Controlled Authorization Network](https://github.com/ucan-wg/spec/) model and how it contrasts with decentralized approaches
|
||||
- APAC/ASEAN Community Call now a colloaborative initative between DIF and ToIP, launched Thursday 26th May 2022, kicking off with an IIW34 recap. ([Recording](https://us02web.zoom.us/rec/share/5FW6hVoZc1kVJiFL4NNCRZg7625h-1UsC1xCY8Mb7cLXQpO2yDW566woLoA5IZA.MUVPrrNr_k3PXxDl)
|
||||
* [DIF Steering Committee Election Results 2022](https://blog.identity.foundation/sc-election-2022-results/)
|
||||
|
||||
SC Election results: DIF welcomes new SC members Sam Curren, Daniel Buchner, Karyl Fowler, Rouven Heck, Markus Sabadello & Kaliya Young!
|
||||
|
||||
|
||||
* [Announcing the Artificial Intelligence and Metaverse Technology Task Force](https://trustoverip.org/blog/2022/07/20/announcing-artificial-intelligence-metaverse-technology-task-force/)
|
||||
|
||||
Three new TOIP Task Forces
|
||||
|
||||
The ToIP Technology Stack Working group is starting an - [Artificial Intelligence and the Metaverse (AIM) Task Force](https://trustoverip.org/blog/2022/07/20/announcing-artificial-intelligence-metaverse-technology-task-force/)
|
||||
|
||||
More details are available at [AI & Metaverse Technology Task Force – Home – Confluence (trustoverip.org)](https://wiki.trustoverip.org/pages/viewpage.action?pageId%3D19657312) (next meeting [8/4](https://wiki.trustoverip.org/display/HOME/Calendar%2Bof%2BToIP%2BMeetings))
|
||||
|
||||
The ToIP Governance Stack Working group is starting a - Governance Architecture Task Force
|
||||
|
||||
After the original development of the [ToIP Governance Architecture Specification](https://trustoverip.org/permalink/ToIP-Governance-Architecture-Specification-V1.0-2021-12-21.pdf) and ToIP [Governance Metamodel Specification](https://trustoverip.org/permalink/ToIP-Governance-Metamodel-Specification-V1.0-2021-12-21.pdf), the plan had been to start creating layer-specific templates. However the Governance Layer TF, led by Alex Tweeddale, Carly Huitema, and Kyle Robinson—with input from Stephen Curran— concluded that component-based templates made more sense. Thus the new Governance Architecture TF will launch based on the components in the ToIP Tech Architecture Stack
|
||||
|
||||
The ToIP Concepts and Terminology Working group is proposing starting a - Mental Models Task Force
|
||||
|
||||
- Mental models explain in detail how a set of concepts are related within a specific domain—a “mini-ontology”
|
||||
- They are usually documented both in writing and in UML diagrams
|
||||
- They add much greater depth and cross-conceptual understanding than glossaries alone
|
||||
- The CTWG is proposing to start up a new Mental Models Task Force in September if there is sufficient interest
|
||||
|
||||
If you are interested Ping the ToIP Slack channel: #concepts-terminology-wg or email Judith@trustoverip.org
|
||||
|
||||
@ -44,20 +44,6 @@ Purple - General crypto packaging/protocol standards
|
||||
|
||||
Orange - Application layer standards
|
||||
|
||||
* [did:orb slides Troy Ronda (SecureKey)](https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0017.html)
|
||||
|
||||
The slides for today’s did:orb presentation can be found here
|
||||
|
||||
Motivation – Enable monitorable ledgers
|
||||
|
||||
- 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.
|
||||
|
||||
* [Technical Report on the Universal RDF Dataset Normalization Algorithm](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/att-0032/Mirabolic_Graph_Iso_Report_2020_10_19.pdf) - [Bill Bradley](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0032.html)
|
||||
> The goal of this technical report is to review the Universal RDF Dataset Normalization Algorithm (URDNA2015) for correctness and to provide satisfactory evidence that possible issues with URDNA2015 have been considered and dismissed. We do not lay out the algorithm in its considerable technical detail here, but refer the reader to the proposed technical specification 1 [Longley], a set of proofs by Rachel Arnold and Dave Longely [Arnold], and a reference implementation in Python [DigitalBazaar].
|
||||
@ -86,8 +72,7 @@ Motivation – Enable monitorable ledgers
|
||||
>
|
||||
> “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.”
|
||||
|
||||
* [Mike Jones shares](https://self-issued.info/?p=2136) that CBOR (Concise Binary Object Representation) is officially a [specification at IETF](https://www.rfc-editor.org/rfc/rfc8943) - woohoo! and it is a key part of [ISO’s mDL standard](https://www.iso.org/committee/45144.html) (date fields must use it).
|
||||
> The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
|
||||
|
||||
* [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/)
|
||||
@ -125,8 +110,6 @@ This October report is the most comprehensive review of global standards around
|
||||
- [BIA](https://bialliance.io/) (Interoperability)
|
||||
- [BiTA](https://www.bita.studio/) (Interoperability; DLT requirements)
|
||||
|
||||
* [OpenID Connect Credential Provider](https://medium.com/mattr-global/introducing-oidc-credential-provider-7845391a9881) Mattr
|
||||
* [OIDC Credential Provider](https://mattrglobal.github.io/oidc-client-bound-assertions-spec/) is “an extension to OpenID Connect which enables the end-user to request credentials from an OpenID Provider and manage their own credentials in a digital wallet.”
|
||||
|
||||
* [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.
|
||||
@ -247,6 +230,8 @@ Since February he has also been the informal chair of the [Hospitality and Trav
|
||||
### OpenID trying to make play in the “trusted identities” online space
|
||||
|
||||
* [Global Assured Identity Network White Paper](https://openid.net/2021/09/20/global-assured-identity-network-white-paper/)
|
||||
|
||||
|
||||
* [OIDC with SIOPv2 and DIF Presentation Exchange](https://vimeo.com/630104529) Sphereon
|
||||
|
||||
* [Sign in with Ethereum](https://login.xyz/) is being developed by Spruce
|
||||
@ -261,9 +246,6 @@ Why would you have 75 logins when you could have 1?
|
||||
|
||||
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
|
||||
|
||||
* [TrustBloc - Duty Free Shop use case (CHAPI Save + WACI Share)](https://www.youtube.com/watch?v%3DaagFJBI1fBE)
|
||||
|
||||
This video demonstrates the TrustBloc platform to Issue a W3C Verifiable Credential through CHAPI and Share the Verifiable Credential/Presentation through WACI.
|
||||
|
||||
* [How Yoma Uses Trinsic to Help African Youth Build Digital CVs](https://trinsic.id/customer-story-yoma/)
|
||||
|
||||
@ -341,6 +323,8 @@ BBS+ signature styles are not going to be ready for deployment anytime soon. Thi
|
||||
* [DIDComm Mythconceptions](https://www.youtube.com/watch?v%3DrwvQdRyMeY4) Daniel Hardman
|
||||
|
||||
DIDComm is a peer-to-peer communication technology for SSI (self-sovereign identity) with security and privacy properties rooted in DIDs (decentralized identifiers). Its core value proposition is often misunderstood or oversimplified. This webinar provides a proper mental model.
|
||||
|
||||
|
||||
* [First Public Review Period for OpenID Connect SIOPV2 and OIDC4VP Specifications Started](https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/) OpenID
|
||||
|
||||
- Implementer’s Drafts public review period: Friday, December 17, 2021 to Monday, January 31, 2022 (45 days)
|
||||
@ -382,6 +366,8 @@ This has two purposes:
|
||||
|
||||
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).
|
||||
|
||||
|
||||
|
||||
* [First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved](https://openid.net/2022/02/08/first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications-approved/) OpenID
|
||||
|
||||
- [Self-Issued OpenID Provider v2](https://openid.net/specs/openid-connect-self-issued-v2-1_0-07.html)
|
||||
@ -393,6 +379,7 @@ Most of Hyperledger Indy’s development occurred prior to the completion of the
|
||||
|
||||
* [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
|
||||
|
||||
|
||||
* [Vote for First Implementer’s Drafts of OIDConnect SIOPV2 and OIDC4VP Specifications](https://openid.net/2022/01/18/notice-of-vote-for-first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications/) OpenID
|
||||
|
||||
The official voting period will be between Tuesday, February 1, 2022 and Tuesday, February 8, 2022, following the [45-day review](https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/) of the specifications.
|
||||
@ -430,9 +417,7 @@ Open standards should be developed openly because not enough people work to ensu
|
||||
|
||||
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.
|
||||
|
||||
* [@kimdhamilton](https://twitter.com/kimdhamilton) · [May 25](https://twitter.com/kimdhamilton/status/1397241823190523904)
|
||||
|
||||
I've read every decentralized identity protocol so you don't have to. They all just read like "nothing to see here, just f- right off" Oh, except for OIDC Credential Provider. Well done to them!
|
||||
|
||||
* [Hygiene for a computing pandemic](https://fossandcrafts.org/episodes/20-hygiene-for-a-computing-pandemic.html)
|
||||
|
||||
@ -453,6 +438,8 @@ This week’s CCG teleconference had a great discussion about object capabilitie
|
||||
|
||||
* [What Is ISO 27018:2019? Everything Executives Need to Know](https://auth0.com/blog/what-is-iso-27018-2019-everything-executives-need-to-know/)
|
||||
> ISO 27018 is part of the ISO 27000 family of standards, which define best practices for information security management. ISO 27018 adds new guidelines, enhancements, and security controls to the ISO/IEC 27001 and ISO/IEC 27002 standards, which help cloud service providers better manage the data security risks unique to PII in cloud computing.
|
||||
|
||||
|
||||
* [Differences between SAML, OAuth & OIDC (OpenID Connect)](https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/)
|
||||
> SAML 2.0 - Security Assertion Markup Language
|
||||
>
|
||||
@ -676,6 +663,8 @@ members from across the community come together to test interoperability between
|
||||
- [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)
|
||||
|
||||
|
||||
- [The selective disclosure industry landscape, including Verifiable Credentials and ISO Mobile Driver Licenses (mDL)](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-why-selective-disclosure-00) – [Kristina Yasuda](https://twitter.com/kristinayasuda)
|
||||
- [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
|
||||
- [Beyond JWS: BBS as a new algorithm with advanced capabilities utilizing JWP](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-beyond-jws-bbs-00) – [Tobias Looker](https://twitter.com/tplooker)
|
||||
@ -862,3 +851,26 @@ Extending OAuth and OIDC to support the issuance and presentation of verifiable
|
||||
> about their path towards trusted P2P messaging and announces the [DIDAgent Framework (DAF)](https://github.com/uport-project/daf)
|
||||
>
|
||||
> when we speak about a DID, then we need to be more precise and also speak about the particular DID method of that DID which defines the CRUD operations on a target system such as Ethereum.
|
||||
|
||||
* [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.
|
||||
|
||||
## DIDs
|
||||
|
||||
* [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.
|
||||
|
||||
|
||||
@ -68,20 +68,6 @@ I've written up a layman's article (as I am not a lawyer) introducing this topic
|
||||
|
||||
* [https://www.blockchaincommons.com/articles/Principal-Authority/](https://www.blockchaincommons.com/articles/Principal-Authority/)
|
||||
|
||||
* [Verifiable Driver's Licenses and ISO-18013-5 (mDL)](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0105.html) Manu Sporny (Monday, 29 November)
|
||||
|
||||
Spruce, MATTR, and Digital Bazaar have collaborated on creating an interoperability test suite for something we're calling the "Verifiable Driver's License" (temporary name):
|
||||
|
||||
* [The test suite](http://w3id.org/vdl/interop-reports) demonstrates that a few things are possible in addition to what mDL provides:
|
||||
|
||||
1. The mDL data model can be expressed cleanly using W3C Verifiable Credentials
|
||||
|
||||
* ["Apple launches the first driver’s license and state ID in Wallet with Arizona”](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0231.html) Liam McCarty (Wednesday, 23 March)
|
||||
|
||||
It’s sad and frustrating that this isn’t based on verifiable credentials… it appears vendor lock in is going to be hard to prevent.
|
||||
|
||||
For anyone who missed the November coverage about this, here’s a pretty outrageous CNBC article: "[Apple is sticking taxpayers with part of the bill for rollout of tech giant's digital ID card](https://www.cnbc.com/2021/11/14/apple-sticking-taxpayers-with-part-of-the-bill-for-digital-id-rollout.html)”
|
||||
|
||||
* [On why revocation is important...](https://lists.w3.org/Archives/Public/public-credentials/2022May/0052.html) Mike Prorock (Tuesday, 24 May)
|
||||
>[https://arstechnica.com/information-technology/2022/05/digital-drivers-license-used-by-4m-australians-is-a-snap-to-forge/](https://arstechnica.com/information-technology/2022/05/digital-drivers-license-used-by-4m-australians-is-a-snap-to-forge/)
|
||||
|
||||
@ -595,30 +581,6 @@ Proposal 3: The APIs that use OAS3.0 MUST define the use of a .well-known JSON r
|
||||
|
||||
the fundamental issue is that stringing a bunch of consonants together ("HTTP") rarely leads to something easy to say in conversation.
|
||||
|
||||
CHAPI
|
||||
|
||||
* [VC-API Diagram for today. Focus on CHAPI](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0007.html) Joe Andrieu (Tuesday, 2 November)
|
||||
|
||||
|
||||
|
||||
* [chapi.io launches, includes VC playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html) Manu Sporny (Monday, 27 June)
|
||||
|
||||
TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.
|
||||
|
||||
* [chapi.io playground upgrades - credential selector, resident card](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0111.html) Manu Sporny (Wednesday, 27 July)
|
||||
|
||||
The credential selector is an icon-based selector for all the credentials that the chapi.io playground currently supports issuing. You can now click on an image of the credential you'd like to issue.
|
||||
|
||||
* [...]
|
||||
|
||||
We have added a permanent resident card from the fictitious Government of Utopia to the list of credentials that can be issued. This credential uses the Citizenship Vocabulary[...]
|
||||
|
||||
* [You can try both of these new features out in the playground](https://playground.chapi.io/issuer)
|
||||
|
||||
* [Jobs For The Future VC added to chapi.io playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0031.html) Manu Sporny (Wednesday, 13 July)
|
||||
|
||||
TL;DR: In an attempt to support the current Jobs for the Future Plugfest, an Open Badge v3.0 example for an Academic Achievement has been added to the chapi.io playground. You can now see what a JFF badge issuance and transfer to a Holder wallet looks like in CHAPI (on mobile and web, on any device that can run a web browser). Images of the flow are attached.
|
||||
|
||||
## Crypto
|
||||
|
||||
* [FYI: Cryptography Review and Recommendations for W3C VC and W3C DID Implementations by SRI International](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0209.html) John, Anil (Wednesday, 26 January)
|
||||
@ -812,11 +774,6 @@ The reason I asked them was in relation to the questions we have discussed regar
|
||||
|
||||
Clearly GNAP can replace OAuth, but I think you both have now confirmed that GNAP does not replace OIDC, or federated identity...
|
||||
|
||||
* [XMSS: Generating usable test vectors for JOSE and COSE](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0007.html) Orie Steele (Sunday, 3 April)
|
||||
|
||||
We've been working on generating test vectors for: [https://datatracker.ietf.org/doc/html/rfc8391](https://datatracker.ietf.org/doc/html/rfc8391) $1$2
|
||||
|
||||
That we could use to register the `kty` and `alg` for XMSS such that it could be used by JOSE and COSE.
|
||||
|
||||
* [https://github.com/transmute-industries/xmss](https://github.com/transmute-industries/xmss)
|
||||
|
||||
|
||||
25
_posts/identosphere-dump/organizations/TOIP.md
Normal file
25
_posts/identosphere-dump/organizations/TOIP.md
Normal file
@ -0,0 +1,25 @@
|
||||
# Trust over IP Foundation
|
||||
|
||||
* [Announcing the Artificial Intelligence and Metaverse Technology Task Force](https://trustoverip.org/blog/2022/07/20/announcing-artificial-intelligence-metaverse-technology-task-force/)
|
||||
|
||||
Three new TOIP Task Forces
|
||||
|
||||
The ToIP Technology Stack Working group is starting an - [Artificial Intelligence and the Metaverse (AIM) Task Force](https://trustoverip.org/blog/2022/07/20/announcing-artificial-intelligence-metaverse-technology-task-force/)
|
||||
|
||||
More details are available at [AI & Metaverse Technology Task Force – Home – Confluence (trustoverip.org)](https://wiki.trustoverip.org/pages/viewpage.action?pageId%3D19657312) (next meeting [8/4](https://wiki.trustoverip.org/display/HOME/Calendar%2Bof%2BToIP%2BMeetings))
|
||||
|
||||
The ToIP Governance Stack Working group is starting a - Governance Architecture Task Force
|
||||
|
||||
After the original development of the [ToIP Governance Architecture Specification](https://trustoverip.org/permalink/ToIP-Governance-Architecture-Specification-V1.0-2021-12-21.pdf) and ToIP [Governance Metamodel Specification](https://trustoverip.org/permalink/ToIP-Governance-Metamodel-Specification-V1.0-2021-12-21.pdf), the plan had been to start creating layer-specific templates. However the Governance Layer TF, led by Alex Tweeddale, Carly Huitema, and Kyle Robinson—with input from Stephen Curran— concluded that component-based templates made more sense. Thus the new Governance Architecture TF will launch based on the components in the ToIP Tech Architecture Stack
|
||||
|
||||
The ToIP Concepts and Terminology Working group is proposing starting a - Mental Models Task Force
|
||||
|
||||
- Mental models explain in detail how a set of concepts are related within a specific domain—a “mini-ontology”
|
||||
- They are usually documented both in writing and in UML diagrams
|
||||
- They add much greater depth and cross-conceptual understanding than glossaries alone
|
||||
- The CTWG is proposing to start up a new Mental Models Task Force in September if there is sufficient interest
|
||||
|
||||
If you are interested Ping the ToIP Slack channel: #concepts-terminology-wg or email Judith@trustoverip.org
|
||||
- [User Controlled Authorization Network](https://github.com/ucan-wg/spec/) model and how it contrasts with decentralized approaches
|
||||
- APAC/ASEAN Community Call now a colloaborative initative between DIF and ToIP, launched Thursday 26th May 2022, kicking off with an IIW34 recap. ([Recording](https://us02web.zoom.us/rec/share/5FW6hVoZc1kVJiFL4NNCRZg7625h-1UsC1xCY8Mb7cLXQpO2yDW566woLoA5IZA.MUVPrrNr_k3PXxDl)
|
||||
A couple weeks ago Amber Case came and spoke about “[Calm Technology](https://www.youtube.com/watch?v%3DNgyfa4_NuPI)” at the TOIP Human Experience Working Group ([HXWG](https://wiki.trustoverip.org/display/HOME/Human%2BExperience%2BWorking%2BGroup)
|
||||
@ -1,8 +1,7 @@
|
||||
# Kantara
|
||||
|
||||
* [Meet Kantara’s new Executive Director, Kay Chopard](https://www.ubisecure.com/podcast/kay-chopard-kantara/) Lets Talk about Digital Identity
|
||||
|
||||
Kay explores why identity is so critical in so many applications; her hope for more promotion of Kantara’s great work and to advance opportunities for collaboration; Kantara’s new mobile drivers licenses (mDLs) work group; Women in Identity and the problem of lack of diversity in standards working groups; and why access and inclusion is one of the biggest challenges facing identity today.
|
||||
|
||||
* [EIC Speaker Spotlight: Kay Chopard on Driving Digital Trust](https://www.kuppingercole.com/blog/beskers/eic-speaker-spotlight-kay-chopard-driving-digital-trust)
|
||||
The mission of Kantara is to grow and fulfill the market for trustworthy use of identity and personal data. And that's a very broad mission. But to do that, some of the things you see in our mission are words like trust, grow, fulfilling what the market needs.
|
||||
* [Exostar Receives Kantara Initiative’s Identity Assurance Trust Framework Certification](https://www.exostar.com/press/exostar-receives-kantara-initiatives-identity-assurance-trust-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
|
||||
@ -13,13 +12,7 @@ Kay explores why identity is so critical in so many applications; her hope for m
|
||||
> - Asynchronous: Resource owner interactions are asynchronous with respect to the authorization grant
|
||||
> - Policies: Resource owner can configure an AS with rules (policy conditions) for the grant of access, vs. just authorize/deny
|
||||
> - Such configurations are outside UMA’s scope
|
||||
* [Working Group for Privacy Enhancing Mobile Credentials](https://kantarainitiative.org/introducing-kantaras-working-group-for-privacy-enhancing-mobile-credentials/) Kantara Initiative
|
||||
|
||||
Clearly the use of a driver’s license goes well beyond proving eligibility to drive a vehicle. It has become the de-facto standard for proving that you are who you say you are – and are entitled to the product or service requested. An increasing number of states are adopting mobile ID systems to recognise and verify mobile credentials including driver’s licenses (mDL).
|
||||
|
||||
* [Kantara Releases Report on Identity and Privacy Protection For mobile Driver’s Licenses](https://kantarainitiative.org/kantara-releases-report-on-identity-and-privacy-protection-for-mobile-drivers-licenses/)
|
||||
|
||||
The report outlines how to implement mDL systems as Privacy Enhancing Technologies. It provides guidance on protecting people’s individual privacy and the digital identifiers of an individual who carries or uses an mDL.
|
||||
|
||||
* [OPN-R (Open Public Notice - Rights) - starting Notice & Control Language - for people to use rights and govern identity (govinterop) with @ Kantara, ToiP and W3C Data Privacy Vocabulary using international vocab - from ISO/IEC 29100 Legal Framework Vocabulary](https://iiw.idcommons.net/22F/_OPN-R_-_Open_Public_Notice_-_Rights_-_starting_Notice_and_Control_Language) by Mark Lizar
|
||||
|
||||
@ -45,12 +38,18 @@ ToiP - ISWG - Notice & Consent Task force for a Privacy Controller Credential
|
||||
|
||||
[https://kantarainitiative.org/confluence/display/WA/Privacy+as+Expected%3A+UI+Signalling+a+Consent+Gateway+For+Human+Consent](https://kantarainitiative.org/confluence/display/WA/Privacy%2Bas%2BExpected%253A%2BUI%2BSignalling%2Ba%2BConsent%2BGateway%2BFor%2BHuman%2BConsent)
|
||||
|
||||
* [Kantara lays out trust-building recommendations for mDLs](https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/)
|
||||
|
||||
A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and
|
||||
|
||||
* [Kantara’s Kay Chopard Talks Digital Security, Diversity, and Business Advice](https://kantarainitiative.org/kantaras-kay-chopard-talks-digital-security-diversity-and-business-advice-on-lets-talk-about-digital-identity/) Kantara - DigitalID NZ
|
||||
|
||||
In August, Kantara Executive Director Kay Chopard spoke with Oscar Santolalla on Let’s Talk About Digital Identity, a Ubisecure-produced podcast. Chopard and Santolalla discussed a wide range of topics, including Chopard’s vision for Kantara and the digital security world, her role in supporting diversity and inclusion, and other topics.
|
||||
|
||||
* [https://kantarainitiative.org/confluence/display/WA/Privacy+as+Expected%3A+UI+Signalling+a+Consent+Gateway+For+Human+Consent](https://kantarainitiative.org/confluence/display/WA/Privacy%2Bas%2BExpected%253A%2BUI%2BSignalling%2Ba%2BConsent%2BGateway%2BFor%2BHuman%2BConsent)
|
||||
|
||||
|
||||
* [Meet Kantara’s new Executive Director, Kay Chopard](https://www.ubisecure.com/podcast/kay-chopard-kantara/) Lets Talk about Digital Identity
|
||||
> Kay explores why identity is so critical in so many applications; her hope for more promotion of Kantara’s great work and to advance opportunities for collaboration; Kantara’s new mobile drivers licenses (mDLs) work group; Women in Identity and the problem of lack of diversity in standards working groups; and why access and inclusion is one of the biggest challenges facing identity today.
|
||||
* [Working Group for Privacy Enhancing Mobile Credentials](https://kantarainitiative.org/introducing-kantaras-working-group-for-privacy-enhancing-mobile-credentials/) Kantara Initiative
|
||||
> Clearly the use of a driver’s license goes well beyond proving eligibility to drive a vehicle. It has become the de-facto standard for proving that you are who you say you are – and are entitled to the product or service requested. An increasing number of states are adopting mobile ID systems to recognise and verify mobile credentials including driver’s licenses (mDL).
|
||||
* [Kantara Releases Report on Identity and Privacy Protection For mobile Driver’s Licenses](https://kantarainitiative.org/kantara-releases-report-on-identity-and-privacy-protection-for-mobile-drivers-licenses/)
|
||||
> The report outlines how to implement mDL systems as Privacy Enhancing Technologies. It provides guidance on protecting people’s individual privacy and the digital identifiers of an individual who carries or uses an mDL.
|
||||
* [Kantara lays out trust-building recommendations for mDLs](https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/)
|
||||
> A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and
|
||||
|
||||
@ -591,6 +591,7 @@ In making the code widely accessible, Ontology is accelerating the adoption of d
|
||||
|
||||
This report discusses what the identity verification related requirements for the creation and management of agri-food products (or items) unique identifiers to enable provenance tracking, ensure traceability, facilitate agri-food data integration, enhance governance, protect privacy and confidentiality, inform policies, and improve communications.
|
||||
|
||||
|
||||
* [ISO/IEC 18013-5 vs Self-Sovereign Identity: A proposal for an mDL Verifiable Credential](https://www.procivis.ch/post/iso-iec-18013-5-vs-self-sovereign-identity-a-proposal-for-an-mdl-verifiable-credential) Procivis
|
||||
|
||||
in the context of government identity programs we see it as useful to compare them on the following parameters – background, credential data model & trust anchor and transmission protocols.
|
||||
|
||||
@ -235,11 +235,7 @@ The intention of the European Commission is to allow – or even force – accep
|
||||
* [Beijing will regulate ‘digital humans’ in the metaverse and beyond](https://restofworld.org/2022/beijing-digital-humans-metaverse/) Rest of World
|
||||
|
||||
The plan also signals that Beijing will take a more active role in handling the personal data generated by these platforms. Some of the directives outlined in the plan require any user-facing aspect of the digital human industry to be subject to rules that protect information about and generated by platform users, while also treating user data as a resource to be traded on the country’s new data exchanges.
|
||||
## Community Project on mDL and VCs
|
||||
|
||||
Last week we shared about the [Community Project on mDL and VCs](https://newsletter.identosphere.net/i/73037307/where-the-wc-verifiable-credentials-meets-the-iso-mobile-driving-license)
|
||||
|
||||
Next week we are hosting two community calls to collect input for the project On Sept 27th in [Asia morning time](https://www.eventbrite.com/e/where-the-w3c-vcs-meets-the-iso-180135-mdl-apac-time-tickets-425211377677) and on Sept 27th in [US morning time](https://www.eventbrite.com/e/where-the-w3c-vcs-meets-the-iso-180135-mdl-eu-africa-americas-time-tickets-425242470677).
|
||||
## Hiring
|
||||
|
||||
* [Vinícius Niche @viniciusniche of Truvity shares](https://twitter.com/viniciusniche/status/1570790061217845248)
|
||||
|
||||
@ -331,9 +331,7 @@ Jolocom is currently working on the project “ONCE – Online einfach anmelden
|
||||
|
||||
The project is part of the competitive innovation programme “Showcase Secure Digital Identities” (SSDI) funded by Germany’s Federal Ministry for Economic Affairs and Energy (BMWi) and one of four projects that qualified for the implementation phase.
|
||||
|
||||
* [Kantara lays out trust-building recommendations for mDLs](https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/)
|
||||
|
||||
A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and
|
||||
|
||||
* [\#4 in the LEI Lightbulb Blog Series - Soaring Regulatory Confidence puts LEI at Center of Trust in Payments Ecosystem](https://www.gleif.org/en/newsroom/blog/in-the-lei-lightbulb-blog-series-soaring-regulatory-confidence-puts-lei-at-center-of-trust-in-payments-ecosystem) GLEIF
|
||||
|
||||
@ -593,19 +591,6 @@ The Decision to make EBSI software available for licencing under the [European U
|
||||
|
||||
* [ID.me](https://www.id.me/)’s legal woes are continuing to escalate. The company is now staring down the prospect of its second federal investigation in as many months, after the House of Representatives’ Oversight and Reform Committee [initiated its review in April](https://findbiometrics.com/congress-opens-formal-investigation-into-id-mes-irs-project-041801/).
|
||||
|
||||
|
||||
* [Mobile Driver’s Licence (mDL) VS. Self-Sovereign Identity (SSI)](https://inatba.org/identity/mobile-drivers-licence-mdl-self-sovereign-identity-ssi-comparison/) INATBA
|
||||
|
||||
The ISO mDL specification (ISO-compliant Driving License or IDL) is purpose driven, as its name implies, but is said to be specifically intended to:
|
||||
|
||||
- enable verifiers not affiliated with or associated with the issuing authority to gain access to and authenticate the information
|
||||
- allow the holder of the driving license to decide what information to release to a verifier
|
||||
- include the ability to update information frequently, and to authenticate information at a high level of confidence.
|
||||
|
||||
* [“Decentralised Identity: What’s at Stake?”](https://inatba.org/wp-content/uploads/2020/11/2020-11-INATBA-Decentralised-Identity-001.pdf). ← earlier paper
|
||||
|
||||
Looking at the above comparison, It is clear that both approaches strive to maintain user control of their personal data, selective disclosure/data minimization, and cryptographic methods to prove the integrity of identity claims. The differences are: first in their reliance (mDL) or independence (SSI) from issuer involvement in verification interactions, and second in their cryptographic approach, where the mDL relies on externally provided cryptographic tools while SSI builds on holder controlled private keys
|
||||
|
||||
* [Enhancing the Privacy of Mobile Credentials, with John Wunderlich](https://www.ubisecure.com/podcast/mobile-credentials-john-wunderlich/) Ubisecure
|
||||
|
||||
what are the challenges and solutions surrounding mobile credentials, what is IAM’s role in this and how systems need to be developed around trust.
|
||||
|
||||
@ -4,27 +4,6 @@ published: false
|
||||
|
||||
# Wallets
|
||||
|
||||
* [Introducing: WACI (Wallet And Credential Interaction)](https://iiw.idcommons.net/4K/_Introducing:_WACI_(Wallet_And_Credential_Interaction)) by Jace Hensley
|
||||
|
||||
* [https://specs.bloom.co/wallet-and-credential-interactions/](https://specs.bloom.co/wallet-and-credential-interactions/)
|
||||
|
||||
* [https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0](https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0)
|
||||
|
||||
Orie linked this related github issue and discussion:[https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84](https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84)
|
||||
Also related: [https://w3c-ccg.github.io/vp-request-spec/#format](https://w3c-ccg.github.io/vp-request-spec/%23format)
|
||||
|
||||
Use cases support mobile wallets, backend services and web apps.
|
||||
Supports chaining of requests…. Relies on credential manifest and presentation exchange
|
||||
|
||||
W3C CCG work seems focussed on the “vc-http-api” and “vp-request-spec” as the solutions to this problem…
|
||||
We reviewed IoT / Web / API considerations for presentation exchange.
|
||||
We notes the following hypothetically viable non interoperable solutions to this problem:
|
||||
1. DIDComm v1 (IIW ticket flows?)
|
||||
2. vp-request-spec + CHAPI
|
||||
|
||||
3. vc-http-api + …. ? / w3c ccg traceability API.
|
||||
|
||||
4. OIDF vp-token spec?
|
||||
|
||||
* [Wallet Security & Hardware-backed VCs - privacy challenges & new DIF WG incoming](https://iiw.idcommons.net/20F/_Wallet_Security_%2526_Hardware-backed_VCs_-_privacy_challenges_%2526_new_DIF_WG_incoming) by Paul Bastian & Micha Kraus
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user