mirror of
https://github.com/Decentralized-ID/decentralized-id.github.io.git
synced 2025-03-03 20:39:16 -05:00
auth, complementary, exchange
This commit is contained in:
parent
b12f5861b6
commit
28856e3c8c
@ -25,14 +25,14 @@
|
|||||||
- Complementary to VC/DID Standards
|
- Complementary to VC/DID Standards
|
||||||
- JSON-LD
|
- JSON-LD
|
||||||
- JSON
|
- JSON
|
||||||
- KERI
|
- KERI ✓
|
||||||
- Cryptography
|
- Cryptography
|
||||||
- BBS
|
- BBS ✓
|
||||||
- Authorization Protocols
|
- Authorization Protocols
|
||||||
- oCap/zCap
|
- oCap/zCap ✓
|
||||||
- UCAN
|
- UCAN ✓
|
||||||
- GNAP
|
- GNAP ✓
|
||||||
- OAuth
|
- OAuth ✓
|
||||||
- Trust Frameworks
|
- Trust Frameworks
|
||||||
- 800-63-3
|
- 800-63-3
|
||||||
- DIACC
|
- DIACC
|
||||||
|
@ -92,39 +92,6 @@ we are pulling together these as an experiment based on feedback from the commun
|
|||||||
|
|
||||||
We also have [IIW33 set now as a virtual event October 12-14](https://www.eventbrite.com/e/internet-identity-workshop-iiwxxxiii-33-2021b-tickets-160257990965) - we had too much uncertainty around travel for folks outside the US who are now 50% of attendees, delta+ variants, fires in California at that time of year and wanting to provide hybrid participation options and not having time.
|
We also have [IIW33 set now as a virtual event October 12-14](https://www.eventbrite.com/e/internet-identity-workshop-iiwxxxiii-33-2021b-tickets-160257990965) - we had too much uncertainty around travel for folks outside the US who are now 50% of attendees, delta+ variants, fires in California at that time of year and wanting to provide hybrid participation options and not having time.
|
||||||
|
|
||||||
* [a few thoughts about zcaps](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0036.html) Nikos Fotiou
|
|
||||||
|
|
||||||
I was reading zcaps draft, as well as related work, mostly macaroons ([https://research.google/pubs/pub41892/](https://research.google/pubs/pub41892/).
|
|
||||||
|
|
||||||
Something that I found confusing about capability documents is that they do not make clear the actions they concern. For example from this [](https://w3c-ccg.github.io/zcap-ld/%23example-1)[https://w3c-ccg.github.io/zcap-ld/#example-1](https://w3c-ccg.github.io/zcap-ld/%23example-1) it is not clear that this is a capability for "driving a car".
|
|
||||||
|
|
||||||
* [Manu Responds:](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0037.html)
|
|
||||||
|
|
||||||
We are still trying to figure out how to explain these things to people.
|
|
||||||
|
|
||||||
Capabilities-based systems are not a new concept; they're decades old at this
|
|
||||||
|
|
||||||
point. The challenge has always been in communicating why they're useful and
|
|
||||||
|
|
||||||
have a place in modern security systems.
|
|
||||||
|
|
||||||
The Encrypted Data Vault work uses zcaps, and it's there that we're trying
|
|
||||||
|
|
||||||
hard to explain to developers how to use it:
|
|
||||||
|
|
||||||
* [https://identity.foundation/confidential-storage/#introduction](https://identity.foundation/confidential-storage/%23introduction)
|
|
||||||
|
|
||||||
* [The "Verifiable" Economy [was RE: a few thoughts about zcaps]](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0047.html) Michael Herman (Trusted Digital Web) (Monday, 5 April)
|
|
||||||
|
|
||||||
After ruminating on ZCAPs, VCs, DIDs, and DID Documents over Easter dinner, it occurred to me that we're on the verge of creating a model for a "verifiable" economy...
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
* [Capability Authorization-enabled Decentralized Object Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about zcaps]]](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0062.html) Michael Herman (Trusted Digital Web) (Wednesday, 7 April)
|
|
||||||
|
|
||||||
I see all of this converging into a Capability Authorization-enabled Decentralized Object Model. “More news at 11…”
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
* [Fake CDC vax cards now being sold to anti-vaxxers](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0077.html) Moses Ma (Thursday, 8 April)
|
* [Fake CDC vax cards now being sold to anti-vaxxers](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0077.html) Moses Ma (Thursday, 8 April)
|
||||||
|
|
||||||
@ -170,37 +137,27 @@ You can view the latest Vaccination Certificate test suite report here:
|
|||||||
|
|
||||||
* [https://w3id.org/vaccination/interop-reports](https://w3id.org/vaccination/interop-reports)
|
* [https://w3id.org/vaccination/interop-reports](https://w3id.org/vaccination/interop-reports)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
* [Regarding CBOR-LD Web Transports](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0100.html) Orie Steele (Saturday, 10 April)
|
* [Regarding CBOR-LD Web Transports](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0100.html) Orie Steele (Saturday, 10 April)
|
||||||
|
> I pushed up this small demo showing how to transport JSON-LD as CBOR-LD over QR Code and Web NFC.
|
||||||
I pushed up this small demo showing how to transport JSON-LD as CBOR-LD over QR Code and Web NFC.
|
* [transmute-industries/cbor-ld-web-transports](https://github.com/transmute-industries/cbor-ld-web-transports) github
|
||||||
|
|
||||||
* [https://github.com/transmute-industries/cbor-ld-web-transports](https://github.com/transmute-industries/cbor-ld-web-transports)
|
|
||||||
|
|
||||||
* [CBOR-LD stabilization (was: Re: Regarding CBOR-LD Web Transports)](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0127.html) Manu Sporny (Wednesday, 21 April)
|
* [CBOR-LD stabilization (was: Re: Regarding CBOR-LD Web Transports)](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0127.html) Manu Sporny (Wednesday, 21 April)
|
||||||
|
> Digital Bazaar has a few updates to share with the community.
|
||||||
Digital Bazaar has a few updates to share with the community.
|
>
|
||||||
|
> 1. With a huge thank you to Dave Longley, a new version of the CBOR-LD library, with generalized and stable algorithms, and that works in the browser and node.js, has been released:
|
||||||
1. With a huge thank you to Dave Longley, a new version of the CBOR-LD library, with generalized and stable algorithms, and that works in the browser and node.js, has been released:
|
>
|
||||||
|
> [https://github.com/digitalbazaar/cborld](https://github.com/digitalbazaar/cborld)
|
||||||
[https://github.com/digitalbazaar/cborld](https://github.com/digitalbazaar/cborld)
|
>
|
||||||
|
> 2. We have split out the CBOR-LD command line interface into a separate project:
|
||||||
2. We have split out the CBOR-LD command line interface into a separate project:
|
>
|
||||||
|
> [https://github.com/digitalbazaar/cborld-cli/tree/initial](https://github.com/digitalbazaar/cborld-cli/tree/initial)
|
||||||
[https://github.com/digitalbazaar/cborld-cli/tree/initial](https://github.com/digitalbazaar/cborld-cli/tree/initial)
|
>
|
||||||
|
> 1. DB has released a CBOR-LD to QR Code image library for encoding and decoding Verifiable Presentations:
|
||||||
1. DB has released a CBOR-LD to QR Code image library for encoding and decoding Verifiable Presentations:
|
>
|
||||||
|
> [https://github.com/digitalbazaar/vpqr](https://github.com/digitalbazaar/vpqr)
|
||||||
[https://github.com/digitalbazaar/vpqr](https://github.com/digitalbazaar/vpqr)
|
>
|
||||||
|
> 1. After some consultation with Mattr and Transmute, we've settled on a base32 alphanumeric QR Code encoding that is 10% more space efficient than base64url byte mode. This is important because this format is compatible with hundreds of QR Code readers on the market. Every QR Code reader that we've tested has worked with this new format.
|
||||||
1. After some consultation with Mattr and Transmute, we've settled on a base32 alphanumeric QR Code encoding that is 10% more space efficient than base64url byte mode. This is important because this format is compatible with hundreds of QR Code readers on the market. Every QR Code reader that we've tested has worked with this new format.
|
|
||||||
|
|
||||||
* [OAuth2.0 and VCs](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0152.html) Nikos Fotiou
|
|
||||||
|
|
||||||
I would like to share with you a paper we have written and it will be presented at [IEEE ICCCN 2021](http://www.icccn.org/). You can find the paper here [https://arxiv.org/abs/2104.11515](https://arxiv.org/abs/2104.11515) We tried to couple OAuth 2.0 flows with JWT/JWS and VCs in order to implement capabilities-based access control. Our goal was to show gains with minimal changes. Some things that might be of interest:
|
|
||||||
|
|
||||||
- We used Proof-of-Possession Key Semantics for JSON Web Tokens (RFC 7800) instead of credentialSubject `id`
|
|
||||||
- We used OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP),([https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/)) for proving VC ownership
|
|
||||||
- We discuss how Revocation list 2020 has better privacy properties compared to RFC 7662 (which can be used for examining the status of an access token)
|
|
||||||
|
|
||||||
* [Zero Trust Architecture in the White House Executive Order on Cybersecurity](https://lists.w3.org/Archives/Public/public-credentials/2021May/0062.html) Adrian Gropper (Friday, 14 May)
|
* [Zero Trust Architecture in the White House Executive Order on Cybersecurity](https://lists.w3.org/Archives/Public/public-credentials/2021May/0062.html) Adrian Gropper (Friday, 14 May)
|
||||||
|
|
||||||
|
@ -795,10 +795,6 @@ This is excellent work, with lots of references, by Dr. Nuttawut Kongsuwan ([Fin
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
- [Anonymous Credential Part 3: BBS+ Signature](https://medium.com/finema/anonymous-credential-part-3-bbs-signature-26797721ca74)
|
|
||||||
> Compared to the CL signature, the BBS+ signature has much shorter keys and signatures for a comparable level of security. As a result, the BBS+ signature enables fast implementation for anonymous credentials. It can be used in combination with signature proof of knowledge to hide some of credential attributes/messages in a zero-knowledge fashion.
|
|
||||||
|
|
||||||
The BBS+ signature will also soon be available in [Finema](https://finema.co/)’s Identity Wallet! We are excited to see how this technology will make an impact to the society in the coming years.
|
|
||||||
|
|
||||||
* [Trust Frameworks](https://medium.com/mattr-global/learn-concepts-trust-frameworks-ad96a4427991)
|
* [Trust Frameworks](https://medium.com/mattr-global/learn-concepts-trust-frameworks-ad96a4427991)
|
||||||
> Trust frameworks are a foundational component of the web of trust. A trust framework is a common set of best practice standards-based rules that ensure minimum requirements are met for security, privacy, identification management and interoperability through accreditation and governance. These operating rules provide a common framework for ecosystem participants, increasing trust between them.
|
> Trust frameworks are a foundational component of the web of trust. A trust framework is a common set of best practice standards-based rules that ensure minimum requirements are met for security, privacy, identification management and interoperability through accreditation and governance. These operating rules provide a common framework for ecosystem participants, increasing trust between them.
|
||||||
|
@ -79,8 +79,6 @@ One alternative, to create a DIDcomm-based protocol for public profile was discu
|
|||||||
|
|
||||||
In a Self Sovereign Environment supported by Hyperledger Indy / Aries agent framework, Mediator Agent is one of the essential components that acts as postman service between Issuer /Verifier Aries Agent and Mobile Agent.
|
In a Self Sovereign Environment supported by Hyperledger Indy / Aries agent framework, Mediator Agent is one of the essential components that acts as postman service between Issuer /Verifier Aries Agent and Mobile Agent.
|
||||||
|
|
||||||
* [trustbloc/hub-router](https://github.com/trustbloc/hub-router) DIDComm mediator and router with mailbox features.
|
|
||||||
> The TrustBloc hub-router is a working implementation of the Mediator Coordination and the Pickup protocols built using Hyperledger Aries Framework - Go.
|
|
||||||
* [Become a Node Operator](https://indicio.tech/blog/be-a-part-of-the-most-dynamic-network-community-in-decentralized-identity/) Indicio
|
* [Become a Node Operator](https://indicio.tech/blog/be-a-part-of-the-most-dynamic-network-community-in-decentralized-identity/) Indicio
|
||||||
> we’ve seen a rapid rise in demand for robust, stable, and professionally maintained networks to support decentralized identity solutions. It’s not a surprise: decentralized identity’s moment has arrived. That’s why we’ve been hard at work creating Hyperledger Indy networks upon which developers all over the world are building, testing, and launching their solutions.
|
> we’ve seen a rapid rise in demand for robust, stable, and professionally maintained networks to support decentralized identity solutions. It’s not a surprise: decentralized identity’s moment has arrived. That’s why we’ve been hard at work creating Hyperledger Indy networks upon which developers all over the world are building, testing, and launching their solutions.
|
||||||
* [Hyperledger Ursa code review](https://www.hyperledger.org/hyperledger-ursa/2022/05/31/hyperledger-ursa-code-review) Hyperledger
|
* [Hyperledger Ursa code review](https://www.hyperledger.org/hyperledger-ursa/2022/05/31/hyperledger-ursa-code-review) Hyperledger
|
||||||
|
@ -93,9 +93,7 @@ there are many known DID methods, but most of them require you to have a [digita
|
|||||||
|
|
||||||
While this may sound convenient for many of us, it comes with its shortcomings as well.
|
While this may sound convenient for many of us, it comes with its shortcomings as well.
|
||||||
|
|
||||||
* [DIDComm Messaging through libp2p](https://medium.com/uport/didcomm-messaging-through-libp2p-cffe0f06a062) uPort
|
|
||||||
|
|
||||||
Peers would still use their peer ID for [libp2p](https://libp2p.io/) routing and authentication. Alice and Bob would exchange their [DID](https://www.w3.org/TR/did-core/) out of band and will be able to find their counterparty’s peer ID via their [DIDs](https://www.w3.org/TR/did-core/).
|
|
||||||
|
|
||||||
* [Introducing New Tools for Creators to Build Trusted Communities](https://www.civic.com/blog/introducing-new-tools-for-creators-to-build-trusted-communities/) CIVIC
|
* [Introducing New Tools for Creators to Build Trusted Communities](https://www.civic.com/blog/introducing-new-tools-for-creators-to-build-trusted-communities/) CIVIC
|
||||||
|
|
||||||
@ -108,11 +106,6 @@ Our goal is to make the process of building trust easier and more effective for
|
|||||||
This project implements a user authentication flow leveraging an Ethereum wallet for single sign on capabilities across all of Web3.
|
This project implements a user authentication flow leveraging an Ethereum wallet for single sign on capabilities across all of Web3.
|
||||||
|
|
||||||
The technologies used are [DID (decentralized identifiers)](https://www.w3.org/TR/did-core/), [Ceramic](https://ceramic.network/), [3id-connect](https://github.com/ceramicstudio/3id-connect), and [Self.ID](https://developers.ceramic.network/tools/self-id/overview/)
|
The technologies used are [DID (decentralized identifiers)](https://www.w3.org/TR/did-core/), [Ceramic](https://ceramic.network/), [3id-connect](https://github.com/ceramicstudio/3id-connect), and [Self.ID](https://developers.ceramic.network/tools/self-id/overview/)
|
||||||
* [Implement Compound Proof BBS+ Verifiable Credentials Using ASP.NET Core and MATTR](https://damienbod.com/2021/12/13/implement-compound-proof-bbs-verifiable-credentials-using-asp-net-core-and-mattr/) Damien Bod
|
|
||||||
|
|
||||||
The ZKP BBS+ verifiable credentials are issued and stored on a digital wallet using a Self-Issued Identity Provider (SIOP) and OpenID Connect. A compound proof presentation template is created to verify the user data in a single verify.
|
|
||||||
|
|
||||||
Code: [https://github.com/swiss-ssi-group/MattrAspNetCoreCompoundProofBBS](https://github.com/swiss-ssi-group/MattrAspNetCoreCompoundProofBBS)
|
|
||||||
* [DTDL models - Azure Digital Twins | Microsoft Docs](https://docs.microsoft.com/en-us/azure/digital-twins/concepts-models)
|
* [DTDL models - Azure Digital Twins | Microsoft Docs](https://docs.microsoft.com/en-us/azure/digital-twins/concepts-models)
|
||||||
|
|
||||||
MSFT does know how to do to JSON-LD they just pretend not to
|
MSFT does know how to do to JSON-LD they just pretend not to
|
||||||
@ -241,8 +234,7 @@ This is so exciting to see what Wayne and his team are building.
|
|||||||
* [EPS for SSI (Self-Sovereign Identity)](https://kokumai.medium.com/eps-for-ssi-self-sovereign-identity-8c742e2b1d02)
|
* [EPS for SSI (Self-Sovereign Identity)](https://kokumai.medium.com/eps-for-ssi-self-sovereign-identity-8c742e2b1d02)
|
||||||
> In my earlier post, I failed to refer specifically to the people working for Self-Sovereign Identity and the likes of blockchain that support the distributed/decentralised storage of secrets. [...] you might all be interested to hear that the key function of Expanded Password System is to convert images to high-entropy codes that work as very long passwords and also as the seeds of symmetric/asymmetric cryptographic keys.
|
> In my earlier post, I failed to refer specifically to the people working for Self-Sovereign Identity and the likes of blockchain that support the distributed/decentralised storage of secrets. [...] you might all be interested to hear that the key function of Expanded Password System is to convert images to high-entropy codes that work as very long passwords and also as the seeds of symmetric/asymmetric cryptographic keys.
|
||||||
|
|
||||||
* [Mental Models of JSON-LD and what a "Document Loader" really does](https://www.youtube.com/watch?v=-yUbMDft5O0) Orie Steel
|
|
||||||
> and terms like "dereferencing" that trip up even highly experienced senior developers that show up late to the Linked-Data party and its open-world model (complete with its own security model based on different availability assumptions).
|
|
||||||
|
|
||||||
* [Trinsic donates did-key.rs to I&D WG](https://medium.com/decentralized-identity/trinsic-donates-did-key-rs-to-i-d-wg-8a278f37bcd0)
|
* [Trinsic donates did-key.rs to I&D WG](https://medium.com/decentralized-identity/trinsic-donates-did-key-rs-to-i-d-wg-8a278f37bcd0)
|
||||||
> 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.
|
> 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.
|
||||||
@ -287,8 +279,7 @@ This is so exciting to see what Wayne and his team are building.
|
|||||||
>
|
>
|
||||||
> Transmute leverages these workbenches as part of our global trade solutions, where our customers benefit from verifiable data workflows and integrated capabilities.
|
> Transmute leverages these workbenches as part of our global trade solutions, where our customers benefit from verifiable data workflows and integrated capabilities.
|
||||||
|
|
||||||
* [Mattr Releases JSON-LD Lint](https://mattr.global/new-to-json-ld-introducing-json-ld-lint/) By Emily Fry and Tobias Looker, Mattr Global
|
|
||||||
> JSON-LD, based on the ubiquitous JSON technology, is rapidly gaining [adoption](https://w3techs.com/technologies/details/da-jsonld) on the web. [JSON-LD](https://json-ld.org/) is an innovation relevant to both [business minds](https://www.forbes.com/sites/forbestechcouncil/2019/02/25/why-is-json-ld-important-to-businesses/#565e8546e1bf) and developers alike.
|
|
||||||
|
|
||||||
### Code
|
### Code
|
||||||
|
|
||||||
@ -371,9 +362,14 @@ we want to explain what we talk about when we talk about Open Recognition. It bu
|
|||||||
|
|
||||||
► [Credentials as a Service Providing Self Sovereign Identity as a Cloud Service Using Trusted Execution Environments](https://ieeexplore.ieee.org/document/9610297)
|
► [Credentials as a Service Providing Self Sovereign Identity as a Cloud Service Using Trusted Execution Environments](https://ieeexplore.ieee.org/document/9610297)
|
||||||
|
|
||||||
|
* [Hygiene for a computing pandemic](https://fossandcrafts.org/episodes/20-hygiene-for-a-computing-pandemic.html)
|
||||||
|
|
||||||
|
This episode of FOSS and Crafts features Christopher Lemmer Webber discussing the object capability security approach. Its a generalization not specific to VCs, continuing from the conversation on the CCG mailinglist, [Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps](https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html), we shared last month.
|
||||||
|
|
||||||
|
The podcast *show-notes include an epic list of references* supporting the discussion.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
* [EBSI Demo Day](https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI/EBSI%2BDemo%2BDay) ([presentation](https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/464979566/EBSI_Demo_Day.pdf)) ([video playlist](https://www.youtube.com/playlist?list%3DPLPMb0otsCuFLpE4UYiAZ_y3HhP2VX6q8O)
|
* [EBSI Demo Day](https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI/EBSI%2BDemo%2BDay) ([presentation](https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/464979566/EBSI_Demo_Day.pdf)) ([video playlist](https://www.youtube.com/playlist?list%3DPLPMb0otsCuFLpE4UYiAZ_y3HhP2VX6q8O)
|
||||||
|
|
||||||
|
@ -0,0 +1,71 @@
|
|||||||
|
# Authorization Protocols
|
||||||
|
|
||||||
|
## oCap
|
||||||
|
- [Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps](https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html)
|
||||||
|
- You *could* implement zcap-ld on top of VCs…
|
||||||
|
- However, you're actually squishing together what should be a separation of concerns in a way that will become *unhygienic*. Like a lack of proper biological hygiene, the result is sickness in our computing systems.
|
||||||
|
- The observation of "these things seem so similar though!" is true, but you can already make that claim even if you're just looking at the linked data proofs layer. VCs and zcap-ld diverge from there for two very separate purposes: what is said, and what is done.
|
||||||
|
* [CCG Call about ZCaps and OCaps](https://w3c-ccg.github.io/meetings/2021-01-13/audio.ogg) ([minutes](https://w3c-ccg.github.io/meetings/2021-01-13/))
|
||||||
|
|
||||||
|
This week’s CCG teleconference had a great discussion about object capabilities
|
||||||
|
|
||||||
|
> Alan Karp: I've been doing capabilities since I reinvented them in 1996 and I want to make sure we get it right, because when newbies start to use them there are plenty of mistakes that can be made
|
||||||
|
>
|
||||||
|
> [...]
|
||||||
|
> A capability or an OCAP is an unforgeable, transferable, permission to use the thing it designates ... it combines designation with authorization
|
||||||
|
|
||||||
|
* [Building capability-based data security for Ceramic](https://blog.ceramic.network/capability-based-data-security-on-ceramic/)
|
||||||
|
> The 3Box Labs team recently published [a new standard for creating capability containers](https://github.com/ChainAgnostic/CAIPs/pull/74) for accessing decentralized data to the [Chain Agnostic Standards Alliance](https://github.com/ChainAgnostic/CASA). Capability containers are an approach for managing advanced data security and permissions, commonly referred to as “Object Capabilities” or “OCAPs.”
|
||||||
|
- [The impact of self-sovereign identity on the cybersecurity world](https://blog.avast.com/impact-of-self-sovereign-identity-on-cybersecurity)
|
||||||
|
* [The Challenging New World of Privacy & Security](https://youtu.be/JmlvOKg_dS4?t=780) Atlanta Innovation Forum (Enterprise)
|
||||||
|
featuring folks from MSFT, GSM, and Michael Becker. The video looks at the range of risks present in managing identity assets. Its focus is coming from the enterprise-level perspective.
|
||||||
|
|
||||||
|
* [a few thoughts about zcaps](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0036.html) Nikos Fotiou
|
||||||
|
|
||||||
|
I was reading zcaps draft, as well as related work, mostly macaroons ([https://research.google/pubs/pub41892/](https://research.google/pubs/pub41892/).
|
||||||
|
|
||||||
|
Something that I found confusing about capability documents is that they do not make clear the actions they concern. For example from this [](https://w3c-ccg.github.io/zcap-ld/%23example-1)[https://w3c-ccg.github.io/zcap-ld/#example-1](https://w3c-ccg.github.io/zcap-ld/%23example-1) it is not clear that this is a capability for "driving a car".
|
||||||
|
|
||||||
|
* [Manu Responds:](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0037.html)
|
||||||
|
|
||||||
|
We are still trying to figure out how to explain these things to people.
|
||||||
|
|
||||||
|
Capabilities-based systems are not a new concept; they're decades old at this
|
||||||
|
|
||||||
|
point. The challenge has always been in communicating why they're useful and
|
||||||
|
|
||||||
|
have a place in modern security systems.
|
||||||
|
|
||||||
|
The Encrypted Data Vault work uses zcaps, and it's there that we're trying
|
||||||
|
|
||||||
|
hard to explain to developers how to use it:
|
||||||
|
|
||||||
|
* [https://identity.foundation/confidential-storage/#introduction](https://identity.foundation/confidential-storage/%23introduction)
|
||||||
|
|
||||||
|
* [The "Verifiable" Economy [was RE: a few thoughts about zcaps]](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0047.html) Michael Herman (Trusted Digital Web) (Monday, 5 April)
|
||||||
|
|
||||||
|
After ruminating on ZCAPs, VCs, DIDs, and DID Documents over Easter dinner, it occurred to me that we're on the verge of creating a model for a "verifiable" economy...
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
* [Capability Authorization-enabled Decentralized Object Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about zcaps]]](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0062.html) Michael Herman (Trusted Digital Web) (Wednesday, 7 April)
|
||||||
|
|
||||||
|
I see all of this converging into a Capability Authorization-enabled Decentralized Object Model. “More news at 11…”
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
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).
|
||||||
|
|
||||||
|
* [The ezcap library](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0038.html) - Manu Sporny
|
||||||
|
> Now might be a good time to announce some open source tooling a few of us have been working on related to zcaps that is being created to simplify the developer experience when developing with zcaps.
|
||||||
|
* [ezcap (pronounced "Easy Cap")](https://github.com/digitalbazaar/ezcap) - An easy to use, opinionated Authorization Capabilities (zcap) client library for the browser and Node.js.
|
||||||
|
|
||||||
|
## UCAN
|
||||||
|
|
||||||
|
* [Lightweight Credentials for Offers with UCAN](https://blog.fission.codes/lightweight-credentials-ucan/)
|
||||||
|
|
||||||
|
these are the types of use cases that we think can be created and enabled across the web as an open, interoperable standard. And some of it crosses into the work we're doing as [part of the Decentralized Identity Foundation](https://blog.fission.codes/fission-demo-day-may-2021/), too.
|
||||||
|
|
||||||
|
- [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)
|
@ -0,0 +1,27 @@
|
|||||||
|
# GNAP
|
||||||
|
* [FedId CG at W3C and GNAP](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0065.html) Orie Steele (Friday, 7 January)
|
||||||
|
|
||||||
|
I asked them whether they considered GNAP via slack.
|
||||||
|
|
||||||
|
* [https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900](https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900)
|
||||||
|
|
||||||
|
They are chartered here: [](https://fedidcg.github.io/)[https://fedidcg.github.io/](https://fedidcg.github.io/)
|
||||||
|
|
||||||
|
To look at AuthN that breaks when browser primitives are removed.
|
||||||
|
|
||||||
|
They are currently focused on OIDC, SAML, WS-Fed.
|
||||||
|
|
||||||
|
The reason I asked them was in relation to the questions we have discussed regarding "What can GNAP replace".
|
||||||
|
|
||||||
|
Clearly GNAP can replace OAuth, but I think you both have now confirmed that GNAP does not replace OIDC, or federated identity...
|
||||||
|
|
||||||
|
|
||||||
|
### Grant Negotiation and Authorization Protocol (GNAP)
|
||||||
|
|
||||||
|
* [GNAP Editors' Use of GitHub Issues](https://aaronparecki.com/2020/11/25/4/gnap-github-issues)
|
||||||
|
> The editors met yesterday to discuss the issues that were pulled out of the previous draft text and document a process for how to resolve these and future issues. We would like to explain how we plan on using labels on GitHub issues to keep track of discussions and keep things moving.
|
||||||
|
|
||||||
|
* [Genesis of the GNAP working group with Dick Hardt of SignIn.org](https://auth0.com/blog/identity-unlocked-explained-episode-6/). Auth0 Podcast *Identity Unlocked* Vittorio Bertocci
|
||||||
|
> The decision was made to create a new group apart from OAuth, and Dick clarifies that the GNAP working group does not feel constrained by existing technology; GNAP does not need to be backward-compatible, but Dick still hopes that the transition to GNAP will be smooth for those who use it.
|
||||||
|
* [Filling in the GNAP](https://medium.com/@justinsecurity/filling-in-the-gnap-a032453eaf8c)
|
||||||
|
> Justin Richer identity protocol writer and implementer extraordinaire has a very excellent post explaining the new GNAP and all the things that lead to it, including OAuth, OpenID, TxAuth, OAuth3, and OAuth.XYZ. This protocol is a big deal and will be important. It’s just beginning the journey through IETF (Internet Engineering Task Force) the main standards body of the internet.
|
@ -0,0 +1,55 @@
|
|||||||
|
|
||||||
|
* [OAuth2.0 and VCs](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0152.html) Nikos Fotiou
|
||||||
|
> I would like to share with you a paper we have written and it will be presented at [IEEE ICCCN 2021](http://www.icccn.org/). You can find the paper here [https://arxiv.org/abs/2104.11515](https://arxiv.org/abs/2104.11515) We tried to couple OAuth 2.0 flows with JWT/JWS and VCs in order to implement capabilities-based access control. Our goal was to show gains with minimal changes. Some things that might be of interest:
|
||||||
|
>
|
||||||
|
> - We used Proof-of-Possession Key Semantics for JSON Web Tokens (RFC 7800) instead of credentialSubject `id`
|
||||||
|
> - We used OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP),([https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/)) for proving VC ownership
|
||||||
|
> - We discuss how Revocation list 2020 has better privacy properties compared to RFC 7662 (which can be used for examining the status of an access token)
|
||||||
|
* [101 Session: OAuth2](https://iiw.idcommons.net/2B/_101_Session:_OAuth2) by Aaron Parecki
|
||||||
|
* [OAuth 2.0 Simplified](https://aaronparecki.com/oauth-2-simplified/) is a guide to OAuth 2.0 focused on writing clients that gives a clear overview of the spec at an introductory level.
|
||||||
|
> In 2017, I published a longer version of this guide as a book, available on [oauth.com](https://oauth.com/) as well as [a print version](https://oauth2simplified.com). The book guides you through building an OAuth server, and covers many details that are not part of the spec. I published this book in conjunction with [Okta](https://developer.okta.com/).
|
||||||
|
|
||||||
|
* [https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi](https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi)
|
||||||
|
|
||||||
|
* [How OAuth Works](https://www.youtube.com/watch?v%3Dg_aVPdwBTfw%26list%3DPLRyLn6THA5wN05b3qJ6N0OpL3YbritKI-) 12 videos
|
||||||
|
|
||||||
|
* [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)
|
||||||
|
|
||||||
|
OAuth, Javascript, Backend Infrastructure
|
||||||
|
|
||||||
|
When there is an alternative, it is more secure to keep tokens out of the browser.
|
||||||
|
|
||||||
|
Specifically talking about clients which are divided between a front end or javascript app, and backend supporting systems specifically for that/those apps
|
||||||
|
|
||||||
|
Questions on whether this would also apply equivalently to native apps, which may have different capabilities and infrastructure requirements. It likely does work, but
|
||||||
|
|
||||||
|
OAuth in the browser can be complicated and ASs don’t necessarily provide sufficient security features, support web interaction
|
||||||
|
|
||||||
|
Bespoke workarounds acquiring tokens on the backend and passing to the frontend. Implementers may have security issues and not understand how to map best current practices
|
||||||
|
|
||||||
|
TMI BFF
|
||||||
|
|
||||||
|
1. Backend gets and stores tokens, javascript frontend gets a cookie
|
||||||
|
2. Request to backend for access (scopes, potentially resource)
|
||||||
|
3. Backend returns the token, requests new token with appropriate scope, etc.
|
||||||
|
|
||||||
|
* [...]
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
* 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/)
|
||||||
|
|
||||||
|
* OpenID: [Public Review Period for Two Proposed SSE Implementer’s Drafts](https://openid.net/2021/06/07/public-review-period-for-two-proposed-sse-implementers-drafts/)
|
||||||
|
|
||||||
|
* [Matt Flynn: Information Security | Identity & Access Mgmt.](http://360tek.blogspot.com/2021/06/bell-labs-colonial-pipeline-and-multi.html)
|
||||||
|
* [Introducing: The OAuth 2 Game](https://auth0.com/blog/introducing-the-oauth-2-game/)
|
||||||
|
|
||||||
|
It features two dice, one for grants and another for application types. Throw the dice and consult the instructions to discover whether the combination of grant and application type you obtained happens to be a good one! Play a few times, and before you know it, you’ll be familiar with the most common combinations!
|
||||||
|
* [The Nuts and Bolts of OAuth 2.0](https://aaronparecki.com/2020/12/22/14/oauth)
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
75
_posts/identosphere-dump/open-standards/complementary/bbs.md
Normal file
75
_posts/identosphere-dump/open-standards/complementary/bbs.md
Normal file
@ -0,0 +1,75 @@
|
|||||||
|
# BBS
|
||||||
|
|
||||||
|
* [What’s next for BBS+ LD-Proofs?](https://iiw.idcommons.net/13B/_What%2527s_next_for_BBS%252B_LD-Proofs%253F) by Brent Zundel
|
||||||
|
|
||||||
|
* [BBS+ Signatures 2020](https://w3c-ccg.github.io/ldp-bbs2020/)
|
||||||
|
|
||||||
|
- What’s next for BBS+ LD-Proofs?
|
||||||
|
- Implementation in Aries ([https://iiw.animo.id/](https://iiw.animo.id/), Used in SVIP Plugfest
|
||||||
|
- Implementation of BBS+ in Ursa, Core of higher level implementations
|
||||||
|
- Features
|
||||||
|
- Selective Disclosure
|
||||||
|
- Signature blinding
|
||||||
|
- Blinded messages (private holder binding)
|
||||||
|
- BBS+ LD Proofs uses this BBS+ scheme, MATTR provided spec
|
||||||
|
- Combine privacy features with semantic world
|
||||||
|
- Draft spec: [https://github.com/w3c-ccg/ldp-bbs2020/](https://github.com/w3c-ccg/ldp-bbs2020/)
|
||||||
|
- What needs to be refined?
|
||||||
|
- Private holder binding ([https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37)
|
||||||
|
- Do not bind to link secret, bind to keypair. Make keypair per credential
|
||||||
|
- How to participate?
|
||||||
|
- Read the draft BBS+ LD-Proofs spec
|
||||||
|
- Hardware security binding?
|
||||||
|
- Not possible with BLS yet?
|
||||||
|
- Is post-quantum secure?
|
||||||
|
- No. Pairing-based signatures are not post-quantum secure
|
||||||
|
|
||||||
|
Next steps:
|
||||||
|
|
||||||
|
- PRs for Issues 10 and 37 plus editorial pass to wrap up ldp-bbs2020
|
||||||
|
- Brent will do PR for 37 [https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37),
|
||||||
|
- Timo will do PR for 10 [https://github.com/w3c-ccg/ldp-bbs2020/issues/10](https://github.com/w3c-ccg/ldp-bbs2020/issues/10).
|
||||||
|
- Invite everyone to suggest editorial changes
|
||||||
|
- Create WG at DIF for Crypto - first work item BBS+
|
||||||
|
- Tobias will work with Rouven to get that started, [https://github.com/decentralized-identity/org/blob/master/working-group-lifecycle.md](https://github.com/decentralized-identity/org/blob/master/working-group-lifecycle.md)
|
||||||
|
- Brent and Tobias will work together to draft a charter
|
||||||
|
|
||||||
|
Future steps:
|
||||||
|
|
||||||
|
- Possible working group, or addition to DIF C&C WG for work on ldp-bbs2021
|
||||||
|
* [Tobias Looker on BBS+ use cases, DIF Interop WG 25Nov2020](https://www.youtube.com/watch?v=slkbFW6imUk) Tobias Looker, MATTR, Interoperability Working group at DIF:
|
||||||
|
|
||||||
|
- Replay attack protection
|
||||||
|
- Domain-specific identifiers and proofs
|
||||||
|
- New partial-disclosure topographies
|
||||||
|
|
||||||
|
* [Deciphering BBS+ Signatures](https://academy.affinidi.com/deciphering-bbs-signatures-e853bbf437bf) Affinidi
|
||||||
|
|
||||||
|
This digital signature was created by Dan Boneh, Xavier Boyen, and Hovav Shacham using the strong Diffie-Hellman encryption technique, and hence the name BBS (after their respective surnames). The original signature was modified later to include proof of knowledge, and hence the name BBS+
|
||||||
|
* [IIW32: BBS+ and Beyond](https://medium.com/mattr-global/iiw32-bbs-and-beyond-1a41634c15b0) Nader Helmy, Mattr
|
||||||
|
|
||||||
|
One common theme this year was the continued development and adoption of BBS+ signatures, a type of multi-message cryptographic digital signature that enables selective disclosure of verifiable credentials.
|
||||||
|
|
||||||
|
This development is possible due to the fact that BBS+ signatures is a ledger-independent approach to selective disclosure, effectively no custom logic or bespoke infrastructure is needed for these digital signatures to be created, used and understood.
|
||||||
|
* [The Power of a Secret](https://trbouma.medium.com/the-power-of-a-secret-c9fa6a404ea3)
|
||||||
|
> What had been discovered by Whitfield Diffie and Martin Hellman (and also Jame Ellis), is changing the world as we know it. It’s been only 43 years. Yes, that seems like an ice-age ago, but in the grand scheme of history, it is only a wink.
|
||||||
|
* [credential definitions, credential manifests, BBS+, etc](https://lists.w3.org/Archives/Public/public-credentials/2021Feb/0010.html) Daniel Hardman
|
||||||
|
> When Tobias first described Mattr's approach to BBS+ signatures, one of my takeaways was that this changed the Indy mechanism of cred defs in two wonderful ways:
|
||||||
|
> 1. It eliminated the need for lots of keys (only one key, Y, needs to be declared as a credential signing key, instead of a set of keys, Y[0]..Y[n])
|
||||||
|
> 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
|
||||||
|
- [Anonymous Credential Part 3: BBS+ Signature](https://medium.com/finema/anonymous-credential-part-3-bbs-signature-26797721ca74)
|
||||||
|
> Compared to the CL signature, the BBS+ signature has much shorter keys and signatures for a comparable level of security. As a result, the BBS+ signature enables fast implementation for anonymous credentials. It can be used in combination with signature proof of knowledge to hide some of credential attributes/messages in a zero-knowledge fashion.
|
||||||
|
|
||||||
|
The BBS+ signature will also soon be available in [Finema](https://finema.co/)’s Identity Wallet! We are excited to see how this technology will make an impact to the society in the coming years.
|
||||||
|
* [Implement Compound Proof BBS+ Verifiable Credentials Using ASP.NET Core and MATTR](https://damienbod.com/2021/12/13/implement-compound-proof-bbs-verifiable-credentials-using-asp-net-core-and-mattr/) Damien Bod
|
||||||
|
> The ZKP BBS+ verifiable credentials are issued and stored on a digital wallet using a Self-Issued Identity Provider (SIOP) and OpenID Connect. A compound proof presentation template is created to verify the user data in a single verify.
|
||||||
|
> Code: [https://github.com/swiss-ssi-group/MattrAspNetCoreCompoundProofBBS](https://github.com/swiss-ssi-group/MattrAspNetCoreCompoundProofBBS)
|
||||||
|
* [The Perfect Signature Style is the Enemy of the One that Works Today](https://indicio.tech/the-perfect-signature-style-is-the-enemy-of-the-one-that-works-today/) Indicio
|
||||||
|
> BBS+ signature styles are not going to be ready for deployment anytime soon. This is precisely why you should build today and in a way that allows you to add them later.
|
||||||
|
- [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)
|
||||||
|
* [SelfSovereignIdentity_memes](https://twitter.com/SSI_by_memes/status/1578045600833994755)
|
||||||
|
|
||||||
|
Currently, everyone waiting for [#AIP2](https://twitter.com/hashtag/AIP2), which enables [#BBS](https://twitter.com/hashtag/BBS)+ [#Signature](https://twitter.com/hashtag/Signature) in #SSI. Companies already implemented in their products, such as [@trinsic_id](https://twitter.com/trinsic_id) and [@mattrglobal](https://twitter.com/mattrglobal). But ZKP [#predicates](https://twitter.com/hashtag/predicates) are not supported by BBS+, so no ZKP age verification possible. Back to [#AnonCreds](https://twitter.com/hashtag/AnonCreds)?
|
||||||
|
- [aries-rfcs/0646-bbs-credentials#drawbacks](https://github.com/hyperledger/aries-rfcs/tree/main/features/0646-bbs-credentials%23drawbacks)
|
@ -0,0 +1,10 @@
|
|||||||
|
# JSON-LD
|
||||||
|
|
||||||
|
* [JSON-LD Playground](https://json-ld.org/playground/)
|
||||||
|
> Play around with JSON-LD markup by typing out some JSON below and seeing what gets generated from it at the bottom of the page. Pick any of the examples below to get started.
|
||||||
|
>
|
||||||
|
> NOTE: The playground uses [jsonld.js](https://github.com/digitalbazaar/jsonld.js) which [conforms](https://github.com/digitalbazaar/jsonld.js%23conformance) to JSON-LD 1.1 [syntax](https://www.w3.org/TR/json-ld11/) ([errata](https://w3c.github.io/json-ld-syntax/errata/)), [API](https://www.w3.org/TR/json-ld11-api/) ([errata](https://w3c.github.io/json-ld-api/errata/)), and [framing](https://www.w3.org/TR/json-ld11-framing/) ([errata](https://w3c.github.io/json-ld-framing/errata/)). Also see the classic [JSON-LD 1.0 playground](https://json-ld.org/playground/1.0/) and the [RDF Distiller](http://rdf.greggkellogg.net/distiller).
|
||||||
|
* [Mental Models of JSON-LD and what a "Document Loader" really does](https://www.youtube.com/watch?v=-yUbMDft5O0) Orie Steel
|
||||||
|
> and terms like "dereferencing" that trip up even highly experienced senior developers that show up late to the Linked-Data party and its open-world model (complete with its own security model based on different availability assumptions).
|
||||||
|
* [Mattr Releases JSON-LD Lint](https://mattr.global/new-to-json-ld-introducing-json-ld-lint/) By Emily Fry and Tobias Looker, Mattr Global
|
||||||
|
> JSON-LD, based on the ubiquitous JSON technology, is rapidly gaining [adoption](https://w3techs.com/technologies/details/da-jsonld) on the web. [JSON-LD](https://json-ld.org/) is an innovation relevant to both [business minds](https://www.forbes.com/sites/forbestechcouncil/2019/02/25/why-is-json-ld-important-to-businesses/#565e8546e1bf) and developers alike.
|
@ -72,71 +72,9 @@ Final Reports. Namely:
|
|||||||
* [Data Integrity EdDSA Cryptosuite 2020](https://w3c.github.io/cg-reports/credentials/CG-FINAL-di-eddsa-2020-20220724/)
|
* [Data Integrity EdDSA Cryptosuite 2020](https://w3c.github.io/cg-reports/credentials/CG-FINAL-di-eddsa-2020-20220724/)
|
||||||
|
|
||||||
|
|
||||||
* [Lightweight Credentials for Offers with UCAN](https://blog.fission.codes/lightweight-credentials-ucan/)
|
|
||||||
|
|
||||||
these are the types of use cases that we think can be created and enabled across the web as an open, interoperable standard. And some of it crosses into the work we're doing as [part of the Decentralized Identity Foundation](https://blog.fission.codes/fission-demo-day-may-2021/), too.
|
|
||||||
|
|
||||||
* [ZK for Authentication With Nolan and Locke from NuID](https://www.zeroknowledge.fm/154) - ZeroKnowledge Podcast.
|
* [ZK for Authentication With Nolan and Locke from NuID](https://www.zeroknowledge.fm/154) - ZeroKnowledge Podcast.
|
||||||
> Universally Composable Direct Anonymous Attestation by Jan Camenisch , Manu Drijvers , and Anja LehmannPractical UC-Secure Delegatable Credentials with Attributes and Their Application to Blockchain by Jan Camenisch , Manu Drijvers , and Anja LehmannPrivacy-Preserving User-Auditable Pseudonym Systems by Jan Camenisch & Anja Lehmann IBM Research – Zurich
|
> Universally Composable Direct Anonymous Attestation by Jan Camenisch , Manu Drijvers , and Anja LehmannPractical UC-Secure Delegatable Credentials with Attributes and Their Application to Blockchain by Jan Camenisch , Manu Drijvers , and Anja LehmannPrivacy-Preserving User-Auditable Pseudonym Systems by Jan Camenisch & Anja Lehmann IBM Research – Zurich
|
||||||
* [What’s next for BBS+ LD-Proofs?](https://iiw.idcommons.net/13B/_What%2527s_next_for_BBS%252B_LD-Proofs%253F) by Brent Zundel
|
|
||||||
|
|
||||||
* [BBS+ Signatures 2020](https://w3c-ccg.github.io/ldp-bbs2020/)
|
|
||||||
|
|
||||||
- What’s next for BBS+ LD-Proofs?
|
|
||||||
- Implementation in Aries ([https://iiw.animo.id/](https://iiw.animo.id/), Used in SVIP Plugfest
|
|
||||||
- Implementation of BBS+ in Ursa, Core of higher level implementations
|
|
||||||
- Features
|
|
||||||
- Selective Disclosure
|
|
||||||
- Signature blinding
|
|
||||||
- Blinded messages (private holder binding)
|
|
||||||
- BBS+ LD Proofs uses this BBS+ scheme, MATTR provided spec
|
|
||||||
- Combine privacy features with semantic world
|
|
||||||
- Draft spec: [https://github.com/w3c-ccg/ldp-bbs2020/](https://github.com/w3c-ccg/ldp-bbs2020/)
|
|
||||||
- What needs to be refined?
|
|
||||||
- Private holder binding ([https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37)
|
|
||||||
- Do not bind to link secret, bind to keypair. Make keypair per credential
|
|
||||||
- How to participate?
|
|
||||||
- Read the draft BBS+ LD-Proofs spec
|
|
||||||
- Hardware security binding?
|
|
||||||
- Not possible with BLS yet?
|
|
||||||
- Is post-quantum secure?
|
|
||||||
- No. Pairing-based signatures are not post-quantum secure
|
|
||||||
|
|
||||||
Next steps:
|
|
||||||
|
|
||||||
- PRs for Issues 10 and 37 plus editorial pass to wrap up ldp-bbs2020
|
|
||||||
- Brent will do PR for 37 [https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37),
|
|
||||||
- Timo will do PR for 10 [https://github.com/w3c-ccg/ldp-bbs2020/issues/10](https://github.com/w3c-ccg/ldp-bbs2020/issues/10).
|
|
||||||
- Invite everyone to suggest editorial changes
|
|
||||||
- Create WG at DIF for Crypto - first work item BBS+
|
|
||||||
- Tobias will work with Rouven to get that started, [https://github.com/decentralized-identity/org/blob/master/working-group-lifecycle.md](https://github.com/decentralized-identity/org/blob/master/working-group-lifecycle.md)
|
|
||||||
- Brent and Tobias will work together to draft a charter
|
|
||||||
|
|
||||||
Future steps:
|
|
||||||
|
|
||||||
- Possible working group, or addition to DIF C&C WG for work on ldp-bbs2021
|
|
||||||
* [Tobias Looker on BBS+ use cases, DIF Interop WG 25Nov2020](https://www.youtube.com/watch?v=slkbFW6imUk) Tobias Looker, MATTR, Interoperability Working group at DIF:
|
|
||||||
|
|
||||||
- Replay attack protection
|
|
||||||
- Domain-specific identifiers and proofs
|
|
||||||
- New partial-disclosure topographies
|
|
||||||
|
|
||||||
* [Deciphering BBS+ Signatures](https://academy.affinidi.com/deciphering-bbs-signatures-e853bbf437bf) Affinidi
|
|
||||||
|
|
||||||
This digital signature was created by Dan Boneh, Xavier Boyen, and Hovav Shacham using the strong Diffie-Hellman encryption technique, and hence the name BBS (after their respective surnames). The original signature was modified later to include proof of knowledge, and hence the name BBS+
|
|
||||||
* [IIW32: BBS+ and Beyond](https://medium.com/mattr-global/iiw32-bbs-and-beyond-1a41634c15b0) Nader Helmy, Mattr
|
|
||||||
|
|
||||||
One common theme this year was the continued development and adoption of BBS+ signatures, a type of multi-message cryptographic digital signature that enables selective disclosure of verifiable credentials.
|
|
||||||
|
|
||||||
This development is possible due to the fact that BBS+ signatures is a ledger-independent approach to selective disclosure, effectively no custom logic or bespoke infrastructure is needed for these digital signatures to be created, used and understood.
|
|
||||||
* [The Power of a Secret](https://trbouma.medium.com/the-power-of-a-secret-c9fa6a404ea3)
|
|
||||||
> What had been discovered by Whitfield Diffie and Martin Hellman (and also Jame Ellis), is changing the world as we know it. It’s been only 43 years. Yes, that seems like an ice-age ago, but in the grand scheme of history, it is only a wink.
|
|
||||||
* [credential definitions, credential manifests, BBS+, etc](https://lists.w3.org/Archives/Public/public-credentials/2021Feb/0010.html) Daniel Hardman
|
|
||||||
> When Tobias first described Mattr's approach to BBS+ signatures, one of my takeaways was that this changed the Indy mechanism of cred defs in two wonderful ways:
|
|
||||||
> 1. It eliminated the need for lots of keys (only one key, Y, needs to be declared as a credential signing key, instead of a set of keys, Y[0]..Y[n])
|
|
||||||
> 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
|
## Jose-Cose
|
||||||
|
|
||||||
|
@ -61,13 +61,57 @@ application/pdf attachment: [DIDComm_v2_Primer.pdf](https://lists.w3.org/Archive
|
|||||||
* [didcomm-rs implementation](https://drive.google.com/file/d/1dn5f2SqnCeQocOy5quJD9gpMPipKRmdC/view?usp%3Dsharing) presentation
|
* [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
|
- [decentralized-identity/didcomm-rs](https://github.com/decentralized-identity/didcomm-rs) github
|
||||||
|
|
||||||
## Real World
|
* [Trusted P2P Messaging with DIDs, DIDComm and VCs](https://medium.com/uport/trusted-p2p-messaging-with-dids-didcomm-and-vcs-398f4c3f3cda) uPort
|
||||||
- [DIF F2F demo session](https://www.youtube.com/watch?v%3DSaNvIorKQ9I)
|
> 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.
|
||||||
|
* [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.
|
||||||
|
* [FLOSS WEEKLY 685: DIDS AND DIDCOMM](https://twit.tv/shows/floss-weekly/episodes/685) Featuring Sam Curren
|
||||||
|
> Sam Curren unpacks for Doc Searls and Dan Lynch why DIDs and DIDcomm are the best approach to identity—and to making people first-class citizens on the Internet. Curren also discusses the origin story of picos and the advantages of nomadic living and hacking.
|
||||||
|
* [Steering Committee approved the DIDComm Messaging Spec (DIDComm v2)](https://twitter.com/IndicioID/status/1545208982863691777) @IndicioID
|
||||||
|
* [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec/)
|
||||||
|
> DIDComm Messaging enables higher-order protocols that inherit its security, privacy, decentralization, and transport independence. Examples include exchanging verifiable credentials, creating and maintaining relationships, buying and selling, scheduling events, negotiating contracts, voting, presenting tickets for travel, applying to employers or schools or banks, arranging healthcare, and playing games.
|
||||||
|
* [DIDComm v2 reaches approved spec status!](https://blog.identity.foundation/didcomm-v2/) DIF Blog
|
||||||
|
> DIDComm defines how messages are composed into application-level protocols and workflows.
|
||||||
|
* [Advanced DIDComm Messaging](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/advanced-didcomm-messaging.md) By: Karim Stekelenburg (Animo Solutions) -- karim@animo.id Date: 18-07-2022 Version: 0.1
|
||||||
|
> in order for DIDComm to provide a potential replacement for commonly used chat protocols like WhatsApp (Extensible Messaging and Presence Protocol (XMPP)), Telegram (MTProto), or Signal (Signal Protocol), it needs to support modern chat features we use everyday
|
||||||
|
* [DIDComm & DIDComm Messaging](https://medium.com/datev-techblog/didcomm-didcomm-messaging-3e10fbf12bb8) Tim Vorgs, DATEV eG
|
||||||
|
|
||||||
|
* [Blockchain and Self-Sovereign Identity Empowered Cyber Threat Information Sharing Platform](https://www.youtube.com/watch?v%3DlzS49R52PwA) Siddhi
|
||||||
|
> looks interesting and different - uses DIDComm
|
||||||
|
>
|
||||||
|
> Presented in 7th IEEE International Conference on Smart Computing(IEEE SmartComp 2021)
|
||||||
|
* [Timo Glastra @TimoGlastra](https://twitter.com/TimoGlastra/status/1572976791136137216) via Twitter
|
||||||
|
> Just got my first DIDComm protocol published on the [https://didcomm.org](https://t.co/GvWIyysx1k) website.
|
||||||
|
|
||||||
|
* DIDComm: [ECDH-1PU Implementation](https://blog.identity.foundation/ecdh-1pu-implementation/) Identity Foundation
|
||||||
|
|
||||||
|
In short, ECDH-1PU is a key derivation process that allows for sender authenticity and enables a “[Perfect Forward Secrecy](https://www.wired.com/2016/11/what-is-perfect-forward-secrecy/%23:~:text%3DPerfect%2520forward%2520secrecy%2520means%2520that,of%2520the%2520user%27s%2520sensitive%2520data.)” mechanism, in addition to significant performance gains over JWS message nested in a JWE envelope, as used by existign ECDH-ES aproaches.
|
||||||
|
|
||||||
|
- 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 includes Jolocom’s implementation of the specification](http://github.com/jolocom/didcomm-rs) with authcrypt (authenticated encrypted) and most of the low level of the protocol.
|
||||||
|
* [trustbloc/hub-router](https://github.com/trustbloc/hub-router) DIDComm mediator and router with mailbox features.
|
||||||
|
> The TrustBloc hub-router is a working implementation of the Mediator Coordination and the Pickup protocols built using Hyperledger Aries Framework - Go.
|
||||||
|
* [DIDComm Messaging through libp2p](https://medium.com/uport/didcomm-messaging-through-libp2p-cffe0f06a062) uPort
|
||||||
|
> Peers would still use their peer ID for [libp2p](https://libp2p.io/) routing and authentication. Alice and Bob would exchange their [DID](https://www.w3.org/TR/did-core/) out of band and will be able to find their counterparty’s peer ID via their [DIDs](https://www.w3.org/TR/did-core/).
|
||||||
|
* [Announcing Pico Engine 1.0](https://www.windley.com/archives/2021/02/announcing_pico_engine_10.shtml)
|
||||||
|
> In addition to the work on the engine itself, one of the primary workstreams at present is to complete Bruce Conrad's excellent work to use DIDs and DIDComm as the basis for inter-pico communication, called ACA-Pico (Aries Cloud Agent - Pico). [...] This work is important because it will replace the current subscriptions method of connecting heterarchies of picos with DIDComm. [...] because DIDComm is protocological, this will support protocol-based interactions between picos, including credential exchange.
|
||||||
|
* [DIDComm Messaging through libp2p](https://medium.com/uport/didcomm-messaging-through-libp2p-cffe0f06a062) Oliver Terbu
|
||||||
|
> We outlined the next generation decentralized messaging solution built on top of [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec/), [DIDs](https://www.w3.org/TR/did-core/) and [VCs](https://www.w3.org/TR/vc-data-model/) and a [libp2p](https://libp2p.io/) overlay network. We presented how Alice and Bob establish a connection, exchange messages and demonstrated what connection types are supported.
|
||||||
|
* [DIF F2FJan21 - DIDComm Demo Session with Ivan Temchenko, Tobias Looker, and Oliver Terbu](https://www.youtube.com/watch?v=SaNvIorKQ9I&feature=youtu.be)
|
||||||
|
|
||||||
|
During the live demo he showed the message lifecycle in various setups using the new, [open source didcomm-rs library](http://github.com/jolocom/didcomm-rs) on GitHub
|
||||||
|
|
||||||
|
|
||||||
|
* [Aries RFC 0453 - credential issuance protocol using DIDComm V1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2)
|
||||||
|
|
||||||
* [The Missing Network Layer Model](https://findy-network.github.io/blog/2022/03/05/the-missing-network-layer-model/) Findy
|
* [Aries RFC 0454 - Present Proof protocol V2 using DIDCommV1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0454-present-proof-v2)
|
||||||
|
|
||||||
Epic Post
|
### 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
|
||||||
|
|
||||||
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?
|
|
||||||
|
@ -47,18 +47,6 @@ 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.
|
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
|
### 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.
|
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.
|
||||||
|
@ -20,19 +20,8 @@ Built on standards: OAuth 2.0 and JWT
|
|||||||
|
|
||||||
See the presentation at [https://self-issued.info/?p=2167](https://self-issued.info/?p%3D2167).
|
See the presentation at [https://self-issued.info/?p=2167](https://self-issued.info/?p%3D2167).
|
||||||
|
|
||||||
* [101 Session: OAuth2](https://iiw.idcommons.net/2B/_101_Session:_OAuth2) by Aaron Parecki
|
|
||||||
|
|
||||||
* [https://aaronparecki.com/tag/iiw](https://aaronparecki.com/tag/iiw)
|
|
||||||
|
|
||||||
* [https://aaronparecki.com/tag/oauth2](https://aaronparecki.com/tag/oauth2)
|
|
||||||
|
|
||||||
* [OAuth 2.0 Simplified](https://aaronparecki.com/oauth-2-simplified/) is a guide to OAuth 2.0 focused on writing clients that gives a clear overview of the spec at an introductory level.
|
|
||||||
|
|
||||||
In 2017, I published a longer version of this guide as a book, available on [oauth.com](https://oauth.com/) as well as [a print version](https://oauth2simplified.com). The book guides you through building an OAuth server, and covers many details that are not part of the spec. I published this book in conjunction with [Okta](https://developer.okta.com/).
|
|
||||||
|
|
||||||
* [https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi](https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi)
|
|
||||||
|
|
||||||
* [How OAuth Works](https://www.youtube.com/watch?v%3Dg_aVPdwBTfw%26list%3DPLRyLn6THA5wN05b3qJ6N0OpL3YbritKI-) 12 videos
|
|
||||||
|
|
||||||
* [101 Session: UMA - User Manged Access](https://iiw.idcommons.net/3B/_101_Session:_UMA_-_User_Managed_Access) by Eve Maler and George Fletcher
|
* [101 Session: UMA - User Manged Access](https://iiw.idcommons.net/3B/_101_Session:_UMA_-_User_Managed_Access) by Eve Maler and George Fletcher
|
||||||
|
|
||||||
@ -58,41 +47,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.
|
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.
|
||||||
|
|
||||||
|
|
||||||
* [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)
|
|
||||||
|
|
||||||
OAuth, Javascript, Backend Infrastructure
|
|
||||||
|
|
||||||
When there is an alternative, it is more secure to keep tokens out of the browser.
|
|
||||||
|
|
||||||
Specifically talking about clients which are divided between a front end or javascript app, and backend supporting systems specifically for that/those apps
|
|
||||||
|
|
||||||
Questions on whether this would also apply equivalently to native apps, which may have different capabilities and infrastructure requirements. It likely does work, but
|
|
||||||
|
|
||||||
OAuth in the browser can be complicated and ASs don’t necessarily provide sufficient security features, support web interaction
|
|
||||||
|
|
||||||
Bespoke workarounds acquiring tokens on the backend and passing to the frontend. Implementers may have security issues and not understand how to map best current practices
|
|
||||||
|
|
||||||
TMI BFF
|
|
||||||
|
|
||||||
1. Backend gets and stores tokens, javascript frontend gets a cookie
|
|
||||||
2. Request to backend for access (scopes, potentially resource)
|
|
||||||
3. Backend returns the token, requests new token with appropriate scope, etc.
|
|
||||||
|
|
||||||
* [...]
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
* 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/)
|
|
||||||
|
|
||||||
* OpenID: [Public Review Period for Two Proposed SSE Implementer’s Drafts](https://openid.net/2021/06/07/public-review-period-for-two-proposed-sse-implementers-drafts/)
|
|
||||||
|
|
||||||
* [Matt Flynn: Information Security | Identity & Access Mgmt.](http://360tek.blogspot.com/2021/06/bell-labs-colonial-pipeline-and-multi.html)
|
|
||||||
* [Introducing: The OAuth 2 Game](https://auth0.com/blog/introducing-the-oauth-2-game/)
|
|
||||||
|
|
||||||
It features two dice, one for grants and another for application types. Throw the dice and consult the instructions to discover whether the combination of grant and application type you obtained happens to be a good one! Play a few times, and before you know it, you’ll be familiar with the most common combinations!
|
|
||||||
* [Police in Latin America are turning activists’ phones against them](https://restofworld.org/2021/latin-america-phone-security/)
|
* [Police in Latin America are turning activists’ phones against them](https://restofworld.org/2021/latin-america-phone-security/)
|
||||||
|
|
||||||
Experts say that seized devices have become a trove of information for authorities cracking down on social movements and opposition leaders.
|
Experts say that seized devices have become a trove of information for authorities cracking down on social movements and opposition leaders.
|
||||||
|
@ -56,22 +56,7 @@ The conversation meanders through deeper details, from how the current [SIOP sp
|
|||||||
|
|
||||||
## Identity Not SSI
|
## Identity Not SSI
|
||||||
|
|
||||||
* [The Nuts and Bolts of OAuth 2.0](https://aaronparecki.com/2020/12/22/14/oauth)
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
### Grant Negotiation and Authorization Protocol (GNAP)
|
|
||||||
|
|
||||||
* [GNAP Editors' Use of GitHub Issues](https://aaronparecki.com/2020/11/25/4/gnap-github-issues)
|
|
||||||
> The editors met yesterday to discuss the issues that were pulled out of the previous draft text and document a process for how to resolve these and future issues. We would like to explain how we plan on using labels on GitHub issues to keep track of discussions and keep things moving.
|
|
||||||
|
|
||||||
* [Genesis of the GNAP working group with Dick Hardt of SignIn.org](https://auth0.com/blog/identity-unlocked-explained-episode-6/). Auth0 Podcast *Identity Unlocked* Vittorio Bertocci
|
|
||||||
> The decision was made to create a new group apart from OAuth, and Dick clarifies that the GNAP working group does not feel constrained by existing technology; GNAP does not need to be backward-compatible, but Dick still hopes that the transition to GNAP will be smooth for those who use it.
|
|
||||||
* [Filling in the GNAP](https://medium.com/@justinsecurity/filling-in-the-gnap-a032453eaf8c)
|
|
||||||
> Justin Richer identity protocol writer and implementer extraordinaire has a very excellent post explaining the new GNAP and all the things that lead to it, including OAuth, OpenID, TxAuth, OAuth3, and OAuth.XYZ. This protocol is a big deal and will be important. It’s just beginning the journey through IETF (Internet Engineering Task Force) the main standards body of the internet.
|
|
||||||
|
|
||||||
|
|
||||||
* [A Universal Resolver for self-sovereign identifiers](https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c)
|
* [A Universal Resolver for self-sovereign identifiers](https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c)
|
||||||
|
@ -50,10 +50,6 @@ It's not something you're ever rid of... it's something you manage over time;
|
|||||||
- [DID SIOP](https://identity.foundation/did-siop/)
|
- [DID SIOP](https://identity.foundation/did-siop/)
|
||||||
- [DID Comm](https://github.com/decentralized-identity/didcomm-messaging)
|
- [DID Comm](https://github.com/decentralized-identity/didcomm-messaging)
|
||||||
- [Trust over IP Foundation](https://trustoverip.org/)
|
- [Trust over IP Foundation](https://trustoverip.org/)
|
||||||
- [Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps](https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html)
|
|
||||||
- You *could* implement zcap-ld on top of VCs…
|
|
||||||
- However, you're actually squishing together what should be a separation of concerns in a way that will become *unhygienic*. Like a lack of proper biological hygiene, the result is sickness in our computing systems.
|
|
||||||
- The observation of "these things seem so similar though!" is true, but you can already make that claim even if you're just looking at the linked data proofs layer. VCs and zcap-ld diverge from there for two very separate purposes: what is said, and what is done.
|
|
||||||
|
|
||||||
* [distributed ID learning path](https://translate.google.com/translate?sl=auto&tl=en&u=https://kristinayasuda.com/posts/decentralized-identity-catch-up-path/) Christina Yasuda based on [VC-Spec](https://github.com/decentralized-identity/vc-spec-map) Map by Michael Ruminer
|
* [distributed ID learning path](https://translate.google.com/translate?sl=auto&tl=en&u=https://kristinayasuda.com/posts/decentralized-identity-catch-up-path/) Christina Yasuda based on [VC-Spec](https://github.com/decentralized-identity/vc-spec-map) Map by Michael Ruminer
|
||||||
first describes pre-requisite knowledge, including JSON, JSON-LD, JWT, JWS, JWK, JWA, and sometimes CBOR. She then goes on to break down knowledge areas beginning with the basics: DID-Core, DID-Resolution, DID-Spec, DID Use-Cases. Next, she covers Verifiable Credentials with VC-Data Model, VC Use-Cases, and VC-Implementors Guide, and also Transport, Credential Presentation, and Other Data Formats.
|
first describes pre-requisite knowledge, including JSON, JSON-LD, JWT, JWS, JWK, JWA, and sometimes CBOR. She then goes on to break down knowledge areas beginning with the basics: DID-Core, DID-Resolution, DID-Spec, DID Use-Cases. Next, she covers Verifiable Credentials with VC-Data Model, VC Use-Cases, and VC-Implementors Guide, and also Transport, Credential Presentation, and Other Data Formats.
|
||||||
@ -162,11 +158,6 @@ The [W3C WebAuthn](https://www.w3.org/blog/webauthn/) and [FIDO2](https://fidoal
|
|||||||
|
|
||||||
SDTT is a tool from Google which began life as the [Rich Snippets Testing Tool](https://developers.google.com/search/blog/2010/09/rich-snippets-testing-tool-improvements) back in 2010. Last year Google [announced plans](https://developers.google.com/search/blog/2020/07/rich-results-test-out-of-beta) to migrate from SDTT to successor tooling, the [Rich Results Test](https://search.google.com/test/rich-results), alongside plans to "deprecate the Structured Data Testing Tool". The newer Google tooling is focused on helping publishers who are targeting specific schema.org-powered [searc](https://developers.google.com/search/docs/guides/search-gallery)[h features](https://www.blogger.com/) offered by Google, and for these purposes is a huge improvement as it contextualizes many warnings and errors to a specific target application.
|
SDTT is a tool from Google which began life as the [Rich Snippets Testing Tool](https://developers.google.com/search/blog/2010/09/rich-snippets-testing-tool-improvements) back in 2010. Last year Google [announced plans](https://developers.google.com/search/blog/2020/07/rich-results-test-out-of-beta) to migrate from SDTT to successor tooling, the [Rich Results Test](https://search.google.com/test/rich-results), alongside plans to "deprecate the Structured Data Testing Tool". The newer Google tooling is focused on helping publishers who are targeting specific schema.org-powered [searc](https://developers.google.com/search/docs/guides/search-gallery)[h features](https://www.blogger.com/) offered by Google, and for these purposes is a huge improvement as it contextualizes many warnings and errors to a specific target application.
|
||||||
|
|
||||||
* [JSON-LD Playground](https://json-ld.org/playground/)
|
|
||||||
|
|
||||||
Play around with JSON-LD markup by typing out some JSON below and seeing what gets generated from it at the bottom of the page. Pick any of the examples below to get started.
|
|
||||||
|
|
||||||
NOTE: The playground uses [jsonld.js](https://github.com/digitalbazaar/jsonld.js) which [conforms](https://github.com/digitalbazaar/jsonld.js%23conformance) to JSON-LD 1.1 [syntax](https://www.w3.org/TR/json-ld11/) ([errata](https://w3c.github.io/json-ld-syntax/errata/)), [API](https://www.w3.org/TR/json-ld11-api/) ([errata](https://w3c.github.io/json-ld-api/errata/)), and [framing](https://www.w3.org/TR/json-ld11-framing/) ([errata](https://w3c.github.io/json-ld-framing/errata/)). Also see the classic [JSON-LD 1.0 playground](https://json-ld.org/playground/1.0/) and the [RDF Distiller](http://rdf.greggkellogg.net/distiller).
|
|
||||||
## Standards
|
## Standards
|
||||||
* [Do I Need a Verifiable Credential?](https://community.rsa.com/t5/rsa-labs-blog/do-i-need-a-verifiable-credential/ba-p/610241)
|
* [Do I Need a Verifiable Credential?](https://community.rsa.com/t5/rsa-labs-blog/do-i-need-a-verifiable-credential/ba-p/610241)
|
||||||
* [What is a DID? Part 1](https://www.youtube.com/watch?v%3DOYYtxVEra1c) XSL Labs
|
* [What is a DID? Part 1](https://www.youtube.com/watch?v%3DOYYtxVEra1c) XSL Labs
|
||||||
@ -246,10 +237,6 @@ I gave the following presentation on the [OpenID Connect Working Group](https:/
|
|||||||
|
|
||||||
JSON has its place. But I think we're overusing it in places where a good notation would serve us better.
|
JSON has its place. But I think we're overusing it in places where a good notation would serve us better.
|
||||||
|
|
||||||
* DIDComm: [ECDH-1PU Implementation](https://blog.identity.foundation/ecdh-1pu-implementation/) Identity Foundation
|
|
||||||
|
|
||||||
In short, ECDH-1PU is a key derivation process that allows for sender authenticity and enables a “[Perfect Forward Secrecy](https://www.wired.com/2016/11/what-is-perfect-forward-secrecy/%23:~:text%3DPerfect%2520forward%2520secrecy%2520means%2520that,of%2520the%2520user%27s%2520sensitive%2520data.)” mechanism, in addition to significant performance gains over JWS message nested in a JWE envelope, as used by existign ECDH-ES aproaches.
|
|
||||||
|
|
||||||
* [Q&A: The Potential of Decentralized ID in Travel](https://www.webintravel.com/qa-the-potential-of-decentralized-digital-id-in-travel/) WebInTravel
|
* [Q&A: The Potential of Decentralized ID in Travel](https://www.webintravel.com/qa-the-potential-of-decentralized-digital-id-in-travel/) WebInTravel
|
||||||
|
|
||||||
Since February he has also been the informal chair of the [Hospitality and Travel Special Interest Group](https://www.notion.so/dif/HOSPITALITY-TRAVEL-SIG-242105321e1747f8bce776bf634a55b3), a subset within the Decentralized Identity Foundation, an organization creating technical specifications and reference implementations for decentralized identity and working with industries for commercial applications of such technologies.
|
Since February he has also been the informal chair of the [Hospitality and Travel Special Interest Group](https://www.notion.so/dif/HOSPITALITY-TRAVEL-SIG-242105321e1747f8bce776bf634a55b3), a subset within the Decentralized Identity Foundation, an organization creating technical specifications and reference implementations for decentralized identity and working with industries for commercial applications of such technologies.
|
||||||
@ -340,13 +327,7 @@ We make a link between a domain and a DID by implementing an open standard writt
|
|||||||
|
|
||||||
Recently, the WAO team took the opportunity to update the badge platforms page on Badge Wiki, a knowledgebase for the Open Badge community. As the ecosystem continues to evolve we’re seeing some early platforms fall by the wayside and new platforms emerge.
|
Recently, the WAO team took the opportunity to update the badge platforms page on Badge Wiki, a knowledgebase for the Open Badge community. As the ecosystem continues to evolve we’re seeing some early platforms fall by the wayside and new platforms emerge.
|
||||||
|
|
||||||
* [The Perfect Signature Style is the Enemy of the One that Works Today](https://indicio.tech/the-perfect-signature-style-is-the-enemy-of-the-one-that-works-today/) Indicio
|
|
||||||
|
|
||||||
BBS+ signature styles are not going to be ready for deployment anytime soon. This is precisely why you should build today and in a way that allows you to add them later.
|
|
||||||
|
|
||||||
* [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
|
* [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
|
||||||
@ -367,9 +348,10 @@ Regarding the standard itself metadata and display are entering the default stan
|
|||||||
|
|
||||||
display brings in [a little bit of novelty 2](https://github.com/blockchain-certificates/cert-schema/blob/master/cert_schema/3.0/displaySchema.json%23L6) images or pdfs, in addition to the more classic HTML.
|
display brings in [a little bit of novelty 2](https://github.com/blockchain-certificates/cert-schema/blob/master/cert_schema/3.0/displaySchema.json%23L6) images or pdfs, in addition to the more classic HTML.
|
||||||
|
|
||||||
* [DIDComm Messaging through libp2p](https://medium.com/uport/didcomm-messaging-through-libp2p-cffe0f06a062) Oliver Terbu
|
|
||||||
|
|
||||||
We outlined the next generation decentralized messaging solution built on top of [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec/), [DIDs](https://www.w3.org/TR/did-core/) and [VCs](https://www.w3.org/TR/vc-data-model/) and a [libp2p](https://libp2p.io/) overlay network. We presented how Alice and Bob establish a connection, exchange messages and demonstrated what connection types are supported.
|
|
||||||
|
|
||||||
|
|
||||||
* [Self-Sovereign Identity (SSI) and Verifiable Credentials (VC) in Ocean Protocol](https://port.oceanprotocol.com/t/proposal-walt-id-bringing-self-sovereign-identity-ssi-and-verifiable-credentials-vc-to-ocean-protocol-proof-of-concept/976)
|
* [Self-Sovereign Identity (SSI) and Verifiable Credentials (VC) in Ocean Protocol](https://port.oceanprotocol.com/t/proposal-walt-id-bringing-self-sovereign-identity-ssi-and-verifiable-credentials-vc-to-ocean-protocol-proof-of-concept/976)
|
||||||
|
|
||||||
What already exists, more recently: [fine-grained permissions 1](https://blog.oceanprotocol.com/fine-grained-permissions-now-supported-in-ocean-protocol-4fe434af24b9):
|
What already exists, more recently: [fine-grained permissions 1](https://blog.oceanprotocol.com/fine-grained-permissions-now-supported-in-ocean-protocol-4fe434af24b9):
|
||||||
@ -437,22 +419,10 @@ This is the Use Case Implementation Workstream of the [COVID Credentials Initia
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
* [Hygiene for a computing pandemic](https://fossandcrafts.org/episodes/20-hygiene-for-a-computing-pandemic.html)
|
|
||||||
|
|
||||||
This episode of FOSS and Crafts features Christopher Lemmer Webber discussing the object capability security approach. Its a generalization not specific to VCs, continuing from the conversation on the CCG mailinglist, [Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps](https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html), we shared last month.
|
|
||||||
|
|
||||||
The podcast *show-notes include an epic list of references* supporting the discussion.
|
|
||||||
|
|
||||||
* [@csuwildcat](https://twitter.com/csuwildcat) shares
|
* [@csuwildcat](https://twitter.com/csuwildcat) shares
|
||||||
> As of Friday, we believe v1 of ION is functionally code complete, and the Sidetree Working Group at DIF (@DecentralizedID) should have a v1 spec candidate ready for the underlying protocol by Jan 21st. Public v1 launch of the ION network on Bitcoin mainnet is just weeks away.
|
> As of Friday, we believe v1 of ION is functionally code complete, and the Sidetree Working Group at DIF (@DecentralizedID) should have a v1 spec candidate ready for the underlying protocol by Jan 21st. Public v1 launch of the ION network on Bitcoin mainnet is just weeks away.
|
||||||
* [CCG Call about ZCaps and OCaps](https://w3c-ccg.github.io/meetings/2021-01-13/audio.ogg) ([minutes](https://w3c-ccg.github.io/meetings/2021-01-13/))
|
|
||||||
|
|
||||||
This week’s CCG teleconference had a great discussion about object capabilities
|
|
||||||
|
|
||||||
> Alan Karp: I've been doing capabilities since I reinvented them in 1996 and I want to make sure we get it right, because when newbies start to use them there are plenty of mistakes that can be made
|
|
||||||
>
|
|
||||||
> [...]
|
|
||||||
> A capability or an OCAP is an unforgeable, transferable, permission to use the thing it designates ... it combines designation with authorization
|
|
||||||
|
|
||||||
* [What Is ISO 27018:2019? Everything Executives Need to Know](https://auth0.com/blog/what-is-iso-27018-2019-everything-executives-need-to-know/)
|
* [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.
|
> 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.
|
||||||
@ -575,9 +545,8 @@ Bluesky Community Voices #6: Interoperable Formats [https://twitter.com/i/spaces
|
|||||||
* [Working in Public](https://blueskyweb.xyz/blog/5-4-2022-working-in-public) BlueSky
|
* [Working in Public](https://blueskyweb.xyz/blog/5-4-2022-working-in-public) BlueSky
|
||||||
|
|
||||||
Today we’re releasing [ADX, the “Authenticated Data Experiment”](https://github.com/bluesky-social/adx). Our company's name, “bluesky,” describes the open-ended nature of this project, and the freedom we were given to start from first principles. As we get more concrete, we’ll give more specific names to what we’re building, starting with ADX.
|
Today we’re releasing [ADX, the “Authenticated Data Experiment”](https://github.com/bluesky-social/adx). Our company's name, “bluesky,” describes the open-ended nature of this project, and the freedom we were given to start from first principles. As we get more concrete, we’ll give more specific names to what we’re building, starting with ADX.
|
||||||
* [FLOSS WEEKLY 685: DIDS AND DIDCOMM](https://twit.tv/shows/floss-weekly/episodes/685) Featuring Sam Curren
|
|
||||||
|
|
||||||
Sam Curren unpacks for Doc Searls and Dan Lynch why DIDs and DIDcomm are the best approach to identity—and to making people first-class citizens on the Internet. Curren also discusses the origin story of picos and the advantages of nomadic living and hacking.
|
|
||||||
|
|
||||||
## DID Core advances to recommendation
|
## DID Core advances to recommendation
|
||||||
|
|
||||||
@ -595,11 +564,8 @@ Harrison Tang, CEO of Spokeo, [is the new co-chair of the CCG](https://twitter.c
|
|||||||
|
|
||||||
W3C CCG (World Wide Web Consortium’s Credentials Community Group) aims to explore the creation, storage, presentation, verification, and user control of credentials (i.e. a set of claims made about someone, or a person record).
|
W3C CCG (World Wide Web Consortium’s Credentials Community Group) aims to explore the creation, storage, presentation, verification, and user control of credentials (i.e. a set of claims made about someone, or a person record).
|
||||||
|
|
||||||
* [Steering Committee approved the DIDComm Messaging Spec (DIDComm v2)](https://twitter.com/IndicioID/status/1545208982863691777) @IndicioID
|
|
||||||
|
|
||||||
* [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec/)
|
|
||||||
|
|
||||||
DIDComm Messaging enables higher-order protocols that inherit its security, privacy, decentralization, and transport independence. Examples include exchanging verifiable credentials, creating and maintaining relationships, buying and selling, scheduling events, negotiating contracts, voting, presenting tickets for travel, applying to employers or schools or banks, arranging healthcare, and playing games.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -637,13 +603,10 @@ Since verification is off-chain (and generally fast/inexpensive, depending on th
|
|||||||
|
|
||||||
Part 2 of this 2-part series explains the [did:pkh](https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md)/[CACAO](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md%23simple-summary) variation for Verite data models and flows, which provides an entry path for wallets that may not support sufficient functionality for emerging decentralized identity patterns
|
Part 2 of this 2-part series explains the [did:pkh](https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md)/[CACAO](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md%23simple-summary) variation for Verite data models and flows, which provides an entry path for wallets that may not support sufficient functionality for emerging decentralized identity patterns
|
||||||
|
|
||||||
* [DIDComm v2 reaches approved spec status!](https://blog.identity.foundation/didcomm-v2/) DIF Blog
|
|
||||||
|
|
||||||
DIDComm defines how messages are composed into application-level protocols and workflows.
|
|
||||||
|
|
||||||
* [Advanced DIDComm Messaging](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/advanced-didcomm-messaging.md) By: Karim Stekelenburg (Animo Solutions) -- karim@animo.id Date: 18-07-2022 Version: 0.1
|
|
||||||
|
|
||||||
in order for DIDComm to provide a potential replacement for commonly used chat protocols like WhatsApp (Extensible Messaging and Presence Protocol (XMPP)), Telegram (MTProto), or Signal (Signal Protocol), it needs to support modern chat features we use everyday
|
|
||||||
|
|
||||||
* [Decentralized Identifiers: Implications for Your Data, Payments and Communications](https://newsletter.impervious.ai/decentralized-identifiers-implications-for-your-data-payments-and-communications-2/) Impervious
|
* [Decentralized Identifiers: Implications for Your Data, Payments and Communications](https://newsletter.impervious.ai/decentralized-identifiers-implications-for-your-data-payments-and-communications-2/) Impervious
|
||||||
|
|
||||||
@ -679,7 +642,10 @@ members from across the community come together to test interoperability between
|
|||||||
|
|
||||||
- [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)
|
- [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
|
- [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)
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
* [Aries Agent Test Harness Enhancement Project](https://www.idlab.org/en/aries-agent-test-harness-enhancement-project/) IDLab
|
* [Aries Agent Test Harness Enhancement Project](https://www.idlab.org/en/aries-agent-test-harness-enhancement-project/) IDLab
|
||||||
|
|
||||||
@ -702,8 +668,6 @@ At this stage of the AATH Enhancement Project, two factors helped define its bro
|
|||||||
|
|
||||||
European Commission’s Next Generation Internet (NGI) initiative to lead a project to test the OpenID Foundation’s protocols for transferring verifiable credentials. Crossword’s partners in this project are Spruce Inc from the USA and Fraunhofer from Germany
|
European Commission’s Next Generation Internet (NGI) initiative to lead a project to test the OpenID Foundation’s protocols for transferring verifiable credentials. Crossword’s partners in this project are Spruce Inc from the USA and Fraunhofer from Germany
|
||||||
|
|
||||||
* [DIDComm & DIDComm Messaging](https://medium.com/datev-techblog/didcomm-didcomm-messaging-3e10fbf12bb8) Tim Vorgs, DATEV eG
|
|
||||||
|
|
||||||
* [Trinsic Builds Open Source Trust Registry Sponsored by eSSIF-Lab](https://trinsic.id/trinsic-builds-open-source-trust-registry-sponsored-by-essif-lab/) Trinsic
|
* [Trinsic Builds Open Source Trust Registry Sponsored by eSSIF-Lab](https://trinsic.id/trinsic-builds-open-source-trust-registry-sponsored-by-essif-lab/) Trinsic
|
||||||
|
|
||||||
Driven by our motivation to make SSI more adoptable, we built the world’s first turn-key, open source trust registry solution. This work was sponsored by the [European Self-Sovereign Identity Framework Lab](https://essif-lab.eu/), which is an EU consortium that provides funding for projects that build SSI open source tools. Any ecosystem provider can use the trust registry implementation to enable governance in their verifiable data ecosystem.
|
Driven by our motivation to make SSI more adoptable, we built the world’s first turn-key, open source trust registry solution. This work was sponsored by the [European Self-Sovereign Identity Framework Lab](https://essif-lab.eu/), which is an EU consortium that provides funding for projects that build SSI open source tools. Any ecosystem provider can use the trust registry implementation to enable governance in their verifiable data ecosystem.
|
||||||
@ -727,11 +691,6 @@ The concept behind a Trust Registry is that a Wallet needs to know which decentr
|
|||||||
|
|
||||||
tldr :: DID is just an URI :: VC is a cryptographically verifiable credential using DID :: SSI is a self-sovereign and privacy-preserving identity :: Non-human (Machines, Bots, Goods, anything) also able to have DID, VC, and SSIs
|
tldr :: DID is just an URI :: VC is a cryptographically verifiable credential using DID :: SSI is a self-sovereign and privacy-preserving identity :: Non-human (Machines, Bots, Goods, anything) also able to have DID, VC, and SSIs
|
||||||
|
|
||||||
* [Blockchain and Self-Sovereign Identity Empowered Cyber Threat Information Sharing Platform](https://www.youtube.com/watch?v%3DlzS49R52PwA) Siddhi
|
|
||||||
|
|
||||||
looks interesting and different - uses DIDComm
|
|
||||||
|
|
||||||
Presented in 7th IEEE International Conference on Smart Computing(IEEE SmartComp 2021)
|
|
||||||
|
|
||||||
* [BCGov improves sustainability reporting with digital trust technology](https://trustoverip.org/blog/2022/08/29/toip-steering-committee-member-the-government-of-british-columbia-improves-sustainability-reporting-with-digital-trust-technology/) ToIP
|
* [BCGov improves sustainability reporting with digital trust technology](https://trustoverip.org/blog/2022/08/29/toip-steering-committee-member-the-government-of-british-columbia-improves-sustainability-reporting-with-digital-trust-technology/) ToIP
|
||||||
|
|
||||||
@ -775,9 +734,6 @@ Good news to see Cardano jumping on the bandwagon, looks like they will join the
|
|||||||
|
|
||||||
The recent DID core specification approval at the World Wide Web Consortium (W3C) provided clearer and stronger foundations for identity platforms building decentralized identifiers.
|
The recent DID core specification approval at the World Wide Web Consortium (W3C) provided clearer and stronger foundations for identity platforms building decentralized identifiers.
|
||||||
|
|
||||||
* [Timo Glastra @TimoGlastra](https://twitter.com/TimoGlastra/status/1572976791136137216) via Twitter
|
|
||||||
|
|
||||||
Just got my first DIDComm protocol published on the [https://didcomm.org](https://t.co/GvWIyysx1k) website.
|
|
||||||
|
|
||||||
* [Circle and Industry Leaders Have Built the First Decentralized Identity Proof-of-Concept for Crypto Finance using Verite Credentials](https://www.circle.com/en/pressroom/circle-and-industry-leaders-have-built-the-first-decentralized-identity-proof-of-concept-for-crypto-finance-using-verite-credentials) Circle
|
* [Circle and Industry Leaders Have Built the First Decentralized Identity Proof-of-Concept for Crypto Finance using Verite Credentials](https://www.circle.com/en/pressroom/circle-and-industry-leaders-have-built-the-first-decentralized-identity-proof-of-concept-for-crypto-finance-using-verite-credentials) Circle
|
||||||
|
|
||||||
@ -805,11 +761,6 @@ By producing an accessible, open-source wrapper library, Tangle Labs provides an
|
|||||||
|
|
||||||
The discussion gets very concrete when Daniel describes selective disclosure JWT, or SD-JWT, a new IETF specification he is coauthoring that offers a simple and easy-to-adopt approach to produce JWTs capable of supporting selective disclosure. Here at Identity, Unlocked, we are huge fans of this new specification, and we hope this episode will help you get started!
|
The discussion gets very concrete when Daniel describes selective disclosure JWT, or SD-JWT, a new IETF specification he is coauthoring that offers a simple and easy-to-adopt approach to produce JWTs capable of supporting selective disclosure. Here at Identity, Unlocked, we are huge fans of this new specification, and we hope this episode will help you get started!
|
||||||
|
|
||||||
* [SelfSovereignIdentity_memes](https://twitter.com/SSI_by_memes/status/1578045600833994755)
|
|
||||||
|
|
||||||
Currently, everyone waiting for [#AIP2](https://twitter.com/hashtag/AIP2), which enables [#BBS](https://twitter.com/hashtag/BBS)+ [#Signature](https://twitter.com/hashtag/Signature) in #SSI. Companies already implemented in their products, such as [@trinsic_id](https://twitter.com/trinsic_id) and [@mattrglobal](https://twitter.com/mattrglobal). But ZKP [#predicates](https://twitter.com/hashtag/predicates) are not supported by BBS+, so no ZKP age verification possible. Back to [#AnonCreds](https://twitter.com/hashtag/AnonCreds)?
|
|
||||||
|
|
||||||
* [](https://twitter.com/SSI_by_memes/status/1578045600833994755)
|
|
||||||
|
|
||||||
Related resources:
|
Related resources:
|
||||||
|
|
||||||
@ -841,11 +792,6 @@ Extending OAuth and OIDC to support the issuance and presentation of verifiable
|
|||||||
* [Trinsic Basics: What Are SSI Standards?](https://trinsic.id/what-are-ssi-standards/)
|
* [Trinsic Basics: What Are SSI Standards?](https://trinsic.id/what-are-ssi-standards/)
|
||||||
> There are two kinds of standards that Trinsic implements to enable interoperability and avoid vendor lock-in: data model standards and protocol standards.
|
> There are two kinds of standards that Trinsic implements to enable interoperability and avoid vendor lock-in: data model standards and protocol standards.
|
||||||
|
|
||||||
* [Trusted P2P Messaging with DIDs, DIDComm and VCs](https://medium.com/uport/trusted-p2p-messaging-with-dids-didcomm-and-vcs-398f4c3f3cda) uPort
|
|
||||||
> 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)
|
* [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.
|
> 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.
|
||||||
|
|
||||||
@ -1071,22 +1017,6 @@ Here's an [illustration of the relationships between the initial DOMAIN and POOL
|
|||||||
|
|
||||||
Just wanted to update folks here that the C2PA has released version 1.0 of their specification at [https://c2pa.org/specifications/specifications/1.0/index.html](https://c2pa.org/specifications/specifications/1.0/index.html). As previously mentioned, it includes native support for VC’s for use in identification of actors (be they human, organizations, etc.). Thanks to everyone here for their input on our work and helping us to deliver.
|
Just wanted to update folks here that the C2PA has released version 1.0 of their specification at [https://c2pa.org/specifications/specifications/1.0/index.html](https://c2pa.org/specifications/specifications/1.0/index.html). As previously mentioned, it includes native support for VC’s for use in identification of actors (be they human, organizations, etc.). Thanks to everyone here for their input on our work and helping us to deliver.
|
||||||
|
|
||||||
* [FedId CG at W3C and GNAP](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0065.html) Orie Steele (Friday, 7 January)
|
|
||||||
|
|
||||||
I asked them whether they considered GNAP via slack.
|
|
||||||
|
|
||||||
* [https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900](https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900)
|
|
||||||
|
|
||||||
They are chartered here: [](https://fedidcg.github.io/)[https://fedidcg.github.io/](https://fedidcg.github.io/)
|
|
||||||
|
|
||||||
To look at AuthN that breaks when browser primitives are removed.
|
|
||||||
|
|
||||||
They are currently focused on OIDC, SAML, WS-Fed.
|
|
||||||
|
|
||||||
The reason I asked them was in relation to the questions we have discussed regarding "What can GNAP replace".
|
|
||||||
|
|
||||||
Clearly GNAP can replace OAuth, but I think you both have now confirmed that GNAP does not replace OIDC, or federated identity...
|
|
||||||
|
|
||||||
|
|
||||||
* [https://github.com/transmute-industries/xmss](https://github.com/transmute-industries/xmss)
|
* [https://github.com/transmute-industries/xmss](https://github.com/transmute-industries/xmss)
|
||||||
|
|
||||||
|
@ -20,6 +20,5 @@ The ToIP Concepts and Terminology Working group is proposing starting a - Mental
|
|||||||
- The CTWG is proposing to start up a new Mental Models Task Force in September if there is sufficient interest
|
- 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
|
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)
|
|
||||||
|
@ -349,11 +349,6 @@ We’re not convinced that “constraint” is the right theoretical approach fo
|
|||||||
- [Jolocom focused on the Rust KERI implementation](https://github.com/decentralized-identity/keriox/), which we donated to DIF last fall
|
- [Jolocom focused on the Rust KERI implementation](https://github.com/decentralized-identity/keriox/), which we donated to DIF last fall
|
||||||
|
|
||||||
> An example of the KERI DID registrar/resolver integrated in our library can be found here. This is also included in the Jolocom SmartWallet via the SDK integration. (KERI is currently being worked on in the Decentralized Identity Foundation’s Identifiers and Discovery Working Group,)
|
> An example of the KERI DID registrar/resolver integrated in our library can be found here. This is also included in the Jolocom SmartWallet via the SDK integration. (KERI is currently being worked on in the Decentralized Identity Foundation’s Identifiers and Discovery Working Group,)
|
||||||
- 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 includes Jolocom’s implementation of the specification](http://github.com/jolocom/didcomm-rs) with authcrypt (authenticated encrypted) and most of the low level of the protocol.
|
|
||||||
|
|
||||||
* [DIF F2FJan21 - DIDComm Demo Session with Ivan Temchenko, Tobias Looker, and Oliver Terbu](https://www.youtube.com/watch?v=SaNvIorKQ9I&feature=youtu.be)
|
|
||||||
|
|
||||||
During the live demo he showed the message lifecycle in various setups using the new, [open source didcomm-rs library](http://github.com/jolocom/didcomm-rs) on GitHub
|
|
||||||
|
|
||||||
* [2021 OpenID Foundation Board Update](https://openid.net/2021/02/09/2021-openid-foundation-board-update/)
|
* [2021 OpenID Foundation Board Update](https://openid.net/2021/02/09/2021-openid-foundation-board-update/)
|
||||||
> Nat Sakimura and John Bradley were re-elected to new two-year terms as community member representatives. Nat and John’s well-known technical expertise and global thought leadership ensures continuity across working groups and as the Foundation transitions to new leadership in 2021.
|
> Nat Sakimura and John Bradley were re-elected to new two-year terms as community member representatives. Nat and John’s well-known technical expertise and global thought leadership ensures continuity across working groups and as the Foundation transitions to new leadership in 2021.
|
||||||
|
@ -10,3 +10,14 @@ A pertinent example of how this can be applied in the corporate world is this ex
|
|||||||
* [25+ Proof of Concepts (PoCs) for Verifiable Credentials](https://academy.affinidi.com/25-proof-of-concept-poc-for-verifiable-credentials-edf684b592f2) Affinidi
|
* [25+ Proof of Concepts (PoCs) for Verifiable Credentials](https://academy.affinidi.com/25-proof-of-concept-poc-for-verifiable-credentials-edf684b592f2) Affinidi
|
||||||
> Today, we proudly present another 25+ Proof of Concepts for VC implementation. These use cases are a compilation of the [submissions](https://affinidipocathon.devpost.com/) (in no particular order) made by the participants of the Affindi PoCathon 2021.
|
> Today, we proudly present another 25+ Proof of Concepts for VC implementation. These use cases are a compilation of the [submissions](https://affinidipocathon.devpost.com/) (in no particular order) made by the participants of the Affindi PoCathon 2021.
|
||||||
|
|
||||||
|
|
||||||
|
## 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?
|
||||||
|
@ -44,9 +44,6 @@ As we’ll explore in the upcoming and future webinars, Scotland’s opportunity
|
|||||||
> Digi.me’s health pass is built on the same principles as our existing secure data exchange platform, and can be displayed on demand on a user’s phone. It is verified fully private, secure and tamper-proof due to multiple robust security measures including encryption.
|
> Digi.me’s health pass is built on the same principles as our existing secure data exchange platform, and can be displayed on demand on a user’s phone. It is verified fully private, secure and tamper-proof due to multiple robust security measures including encryption.
|
||||||
|
|
||||||
This health pass has been designed to be fully interoperable with other international standards, such as the UN Good Health Pass Collaborative, of which [digi.me is a member](https://blog.digi.me/2021/02/25/digi-me-joins-good-health-pass-collaborative-to-help-build-a-safe-travelling-future/).
|
This health pass has been designed to be fully interoperable with other international standards, such as the UN Good Health Pass Collaborative, of which [digi.me is a member](https://blog.digi.me/2021/02/25/digi-me-joins-good-health-pass-collaborative-to-help-build-a-safe-travelling-future/).
|
||||||
* [The ezcap library](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0038.html) - Manu Sporny
|
|
||||||
> Now might be a good time to announce some open source tooling a few of us have been working on related to zcaps that is being created to simplify the developer experience when developing with zcaps.
|
|
||||||
* [ezcap (pronounced "Easy Cap")](https://github.com/digitalbazaar/ezcap) - An easy to use, opinionated Authorization Capabilities (zcap) client library for the browser and Node.js.
|
|
||||||
|
|
||||||
* [Everything You Need to Know About “Vaccine Passports”](https://identitywoman.net/quoted-in-everything-you-need-to-know-about-vaccine-passports/) IdentityWoman \ [Mother Jones](https://www.motherjones.com/politics/2021/04/everything-you-need-to-know-about-vaccine-passports/)
|
* [Everything You Need to Know About “Vaccine Passports”](https://identitywoman.net/quoted-in-everything-you-need-to-know-about-vaccine-passports/) IdentityWoman \ [Mother Jones](https://www.motherjones.com/politics/2021/04/everything-you-need-to-know-about-vaccine-passports/)
|
||||||
> Andy Slavitt, a White House senior adviser for COVID response, specified at a [March 29](https://www.whitehouse.gov/briefing-room/press-briefings/2021/03/29/press-briefing-by-white-house-covid-19-response-team-and-public-health-officials-21/) briefing that “unlike other parts of the world, the government here is not viewing its role as the place to create a passport, nor a place to hold the data of citizens.”
|
> Andy Slavitt, a White House senior adviser for COVID response, specified at a [March 29](https://www.whitehouse.gov/briefing-room/press-briefings/2021/03/29/press-briefing-by-white-house-covid-19-response-team-and-public-health-officials-21/) briefing that “unlike other parts of the world, the government here is not viewing its role as the place to create a passport, nor a place to hold the data of citizens.”
|
||||||
|
@ -93,11 +93,7 @@ published: false
|
|||||||
> - The security landscape for global enterprises
|
> - The security landscape for global enterprises
|
||||||
> - Decentralized identity, what it is and how it fortifies existing data infrastructure
|
> - Decentralized identity, what it is and how it fortifies existing data infrastructure
|
||||||
> - Case study: applying zero trust and decentralized identity to energy
|
> - Case study: applying zero trust and decentralized identity to energy
|
||||||
* [Building capability-based data security for Ceramic](https://blog.ceramic.network/capability-based-data-security-on-ceramic/)
|
|
||||||
> The 3Box Labs team recently published [a new standard for creating capability containers](https://github.com/ChainAgnostic/CAIPs/pull/74) for accessing decentralized data to the [Chain Agnostic Standards Alliance](https://github.com/ChainAgnostic/CASA). Capability containers are an approach for managing advanced data security and permissions, commonly referred to as “Object Capabilities” or “OCAPs.”
|
|
||||||
- [The impact of self-sovereign identity on the cybersecurity world](https://blog.avast.com/impact-of-self-sovereign-identity-on-cybersecurity)
|
|
||||||
* [The Challenging New World of Privacy & Security](https://youtu.be/JmlvOKg_dS4?t=780) Atlanta Innovation Forum (Enterprise)
|
|
||||||
featuring folks from MSFT, GSM, and Michael Becker. The video looks at the range of risks present in managing identity assets. Its focus is coming from the enterprise-level perspective.
|
|
||||||
* [Can SSI Disrupt Surveillance Capitalism?](https://academy.affinidi.com/can-ssi-disrupt-surveillance-capitalism-5c8cd6b50278) Affinidi
|
* [Can SSI Disrupt Surveillance Capitalism?](https://academy.affinidi.com/can-ssi-disrupt-surveillance-capitalism-5c8cd6b50278) Affinidi
|
||||||
Are these advantages enough to disrupt surveillance capitalism? Do you think SSI is the antidote for today’s Internet identity problems and surveillance capitalism? Please share your thoughts with us.
|
Are these advantages enough to disrupt surveillance capitalism? Do you think SSI is the antidote for today’s Internet identity problems and surveillance capitalism? Please share your thoughts with us.
|
||||||
* [Identity + Security + Privacy = Trust](https://digitalidentity.nz/2021/08/26/identity-security-privacy-trust/) DigitalID NZ
|
* [Identity + Security + Privacy = Trust](https://digitalidentity.nz/2021/08/26/identity-security-privacy-trust/) DigitalID NZ
|
||||||
|
Loading…
x
Reference in New Issue
Block a user