- From: Rein Krul <info@reinkrul.nl>
- Date: Wed, 9 Aug 2023 11:23:38 +0200 (CEST)
- To: Orie Steele <orie@transmute.industries>, Adrian Gropper <agropper@healthurl.com>
- Cc: Mahmoud Alkhraishi <mahmoud@mavennet.com>, W3C Credentials CG <public-credentials@w3.org>, Mike Prorock <mprorock@mesur.io>
- Message-ID: <1675091176.140660.1691573018440@s.appsuite.hostnet.nl>
Looking at IETF GNAP, it can probably support non-browser authz flows in a more semantic manner. And cryptographic keys are treated as first-class citizen (at least more than in OAuth2), which makes combining it with DIDs and VCs easier. But it's still an ongoing effort (draft), just like OAuth 2.1, although that applies to many (most?) SSI-related standards. But as the EU recommends usage of OpenID4VP in its Wallet Architectural Reference Framework (https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-architecture-and-reference-framework-outline), OAuth2 might be the logical choice for services and wallets targeting the EU (although the framework does not specify m2m interactions). Best regards, Rein > Op 8 augustus 2023 om 21:47 schreef Adrian Gropper <agropper@healthurl.com>: > > VCs are always offered (presented) or consumed by a user agent. In general, the user agent can be either a client (e.g. a mobile wallet) or a server (e.g. an authorized cloud agent). > > From a decentralization and self-sovereignty perspective, the issuers and verifiers should support whatever user agent the human subject of a VC is using. As best I can tell, IETF GNAP is the only standard explicitly designed for interop where the human subject of a VC retains the power to choose their user agent. > > I’m curious about what use-cases would still require OAuth now that GNAP is available. > > - Adrian > > > On Tue, Aug 8, 2023 at 1:28 PM Orie Steele <orie@transmute.industries> wrote: > > > > Traceability folks support what we call "OAuth Presentations"... to distinguish them from their VC-API cousins. > > > > - https://github.com/w3c-ccg/traceability-interop > > - https://github.com/w3c-ccg/traceability-vocab > > > > You can see the latest report runs here: https://w3c-ccg.github.io/traceability-interop/reports/interoperability/ > > > > I would say what we are doing is not "vc-api" or "presentation exchange" in the DIF context. > > > > In general, "verifiable presentations" are extremely weakly defined making interop testing very inconsistent, and often "securing mechanism specific". > > > > For example see: > > > > https://openid.net/specs/openid-4-verifiable-presentations-1_0.html > > > > I don't know if anyone is implementing this kind of flow for M2M / machine identity use cases... but that's what we have been wanting for a long time... and why we don't use the current version of the vc api. > > > > There is also: > > > > https://identity.foundation/jwt-vc-presentation-profile/#profile > > > > In general the community seems very fixated on "human in the loop" presentation flows... which are almost completely useless for organization / cloud agent use cases where machines interact on behalf of users without pestering them to confirm transactions. > > > > At the most recent IETF, there seems to be a lot of interest in "client credentials", "private key jwt" and "client attestation" auth modes for OAuth. > > > > It would be nice to see a similar level of interest in M2M / Machine Identity originating verifiable presentation flows. > > > > Regards, > > > > OS > > > > > > On Tue, Aug 8, 2023 at 9:17 AM Manu Sporny < msporny@digitalbazaar.com mailto:msporny@digitalbazaar.com > wrote: > > > > > > > On Mon, Aug 7, 2023 at 10:35 AM Rein Krul < info@reinkrul.nl mailto:info@reinkrul.nl > wrote: > > > > Is there (previous) work on, or interest for, such a standard? Or do you know of any initiatives to standardize it? > > > > > > Hi Rein, > > > > > > There is a group of us that are working on something called the > > > Verifiable Credentials API, which does the sort of server-to-server > > > flows that you mention, where OAuth2 is one of the authentication > > > mechanisms in play. The VC API is a work item of the Credentials CG: > > > > > > https://w3c-ccg.github.io/vc-api/ > > > > > > We do plan to take it onto the standards track once we have enough > > > implementation experience. There are portions of the API that were > > > utilized for the last Jobs for the Future plugfest (mostly the issuer > > > API portions), where a number of the VC API implementers used OAuth2 > > > for the authentication mechanism (see slide #5): > > > > > > https://docs.google.com/presentation/d/19GmJ3bLMrbVadesnkmsWaaUr-U71Y9Kr775tZvgs-xI/edit > > > > > > Here are a number of implementers in the ecosystem demonstrating that > > > the API can be used to interop on credential issuance here (as well): > > > > > > https://w3c-ccg.github.io/vc-api-issuer-test-suite/#Issue%20Credential%20-%20Data%20Integrity > > > > > > For exchanging VCs, we provide these interfaces in the API (again, > > > OAuth2 could be used for server-to-server exchanges): > > > > > > https://w3c-ccg.github.io/vc-api/#exchange-examples > > > > > > All that said, while we plan to take the API standards track, we want > > > to make sure that we're addressing a variety of the diverse > > > server-to-server use cases in the ecosystem, which are being > > > documented here: > > > > > > https://w3c-ccg.github.io/vc-api-use-cases/ > > > > > > Hope that helps. We have weekly calls (Tuesdays at 3pm ET) among a > > > group that is working on the specification. I hope that helps answer > > > some of the question you were asking. Do you have any further > > > questions on any of the above, Rein? > > > > > > -- manu > > > > > > -- > > > Manu Sporny - https://www.linkedin.com/in/manusporny/ > > > Founder/CEO - Digital Bazaar, Inc. > > > https://www.digitalbazaar.com/ > > > > > > > > > > > > > > > -- > > > > > > ORIE STEELE > > Chief Technology Officer > > www.transmute.industries https://transmute.industries > > > > > > >
Received on Wednesday, 9 August 2023 09:24:26 UTC