search

w3c-ccg / community

COMMUNITY: W3C Credentials Community Group Community Repo
https://w3c-ccg.github.io/community
Other
41 stars 6 forks source link

[PROPOSED WORK ITEM] Traceability API #191

Closed OR13 closed 3 years ago

OR13 commented 3 years ago

Traceability API

The world needs an Open Source and Open Standards based HTTP API that is capable of presentation exchange.

We're pretty confident this won't be the end of such APIs and that better solutions with more interoperability will emerge as VCs and DIDs become more commonly used.

We're happy to tombstone the work item / defer to better solution if one ever exists, but we need the ability work together today.

Include Link to Abstract or Draft

(Tests and Implementation Links)

List Owners

@OR13 @mprorock

Work Item Questions

Answer the following questions in order to document how you are meeting the requirements for a new work item at the W3C Credentials Community Group. Please note if this work item supports the Silicon Valley Innovation program or another government or private sector project.

  1. Explain what you are trying to do using no jargon or acronyms.

Enabling businesses to exchange verifiable presentations of critical trade data represented as verifiable credentials over the internet, without requiring the use of a Web Browser or DIDComm.

  1. How is it done today, and what are the limits of the current practice?

Of the two, DIDComm is much closer to what we need, but is unfortunately tangled in Aries ideology and lacks the simple interface and data models we need to support credential exchange over http without pulling in the entire Aries universe.

When DIDComm spec is published we would love to consider a message based API that is compatible with it, but we have no timeline for when that will be possible.

Some might argue that this work item should be all that we need:

However, it lacks the appropriate level of contribution and support for Holders and Verifiable Presentations.

Simply put, there is no consensus on the work item scope, and no UCR, and there is very little contribution to it.

It does not support https://w3c-ccg.github.io/vp-request-spec.

We aim to be compatible with BOTH the vc-http-api AND the vp-request-spec, but we can't afford to be blocked by poor contribution to them, and we can't afford to wait for DIDComm to mature enough to be a better starting building block.

We need a solution that works over HTTP today.

  1. What is new in your approach and why do you think it will be successful?

We wrote the first version of the vc-http-api test suite, and are the number 1 contributor to the work item:

https://github.com/w3c-ccg/vc-http-api/graphs/contributors

We have a well defined use case, and narrow set of requirements, and the skills and software necessary to execute on it.

We have a spec, implementation and test suite that already shows our approach works, and which are 100% compatible with the features the vc-http-api and vp-request-spec have decided NOT to support.

We can't convince the vc-http-api CODEOWNERs to support Verifiable Presentations, they should not be able to block us from doing so, we need a separate work item to make progress :)

  1. How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)

We're using the tools available to us from the W3C CCG, including JITSI meeting software and GitHub.

  1. What actions are you taking to make this work item accessible to a non-technical audience?

We're having regular calls where anyone can join and ask questions. However, this work item is specifically a technical work item, API Spec, Test Suite, and Sample Implementation.

We are not seeking UCR / Design / Product feedback.

vsnt commented 3 years ago

@OR13 thanks for your clear answers to the questions. appreciated.

mprorock commented 3 years ago

Confirming mesur.io is on board with this and that I will act as a co-owner/editor on the spec, testing, etc

David-Chadwick commented 3 years ago 
I agree that we need a standard way for requesting a VP and
  returning one, that is product independent. There are many
  different ideas for what this protocol exchange should be. None
  that I have seen so far agree with how I think it should work.
  Maybe this should be a topic for discussion at IIW?
Kind regards
David

On 12/04/2021 21:04, Orie Steele wrote:

  Traceability API
  The world needs an Open Source and Open Standards based HTTP
    API that is capable of presentation exchange.
  We're pretty confident this won't be the end of such APIs and
    that better solutions with more interoperability will emerge as
    VCs and DIDs become more commonly used.
  We're happy to tombstone the work item / defer to better
    solution if one ever exists, but we need the ability work
    together today.
  Include Link to Abstract or Draft

    https://github.com/OR13/traceability-api

  (Tests and Implementation Links)

    https://github.com/OR13/simple-presentations
    https://github.com/transmute-industries/vc.transmute.world
    https://github.com/transmute-industries/verifiable-data/tree/main/packages/universal-wallet-fastify-plugin

  List Owners

    Identify 1 lead (person responsible for advancing the work
      item) and at least 1 other owner. Ideally, include their
      github usernames

  @OR13
    @mprorock
  Work Item Questions

    Answer the following questions in order to document how you
      are meeting the requirements for a new work item at the W3C
      Credentials Community Group. Please note if this work item
      supports the Silicon Valley Innovation program or another
      government or private sector project.

    Explain what you are trying to do using no jargon or
      acronyms.

  Enabling businesses to exchange verifiable presentations of
    critical trade data represented as verifiable credentials over
    the internet, without requiring the use of a Web Browser or
    DIDComm.

    How is it done today, and what are the limits of the current
      practice?

    https://w3c-ccg.github.io/credential-handler-api/
      (Web Browser)
    https://w3c-ccg.github.io/vp-request-spec/#format
      (Not a transport)
    https://identity.foundation/didcomm-messaging/spec/
      (DIDComm)

  Of the two, DIDComm is much closer to what we need, but is
    unfortunately tangled in Aries ideology and lacks the simple
    interface and data models we need to support credential exchange
    over http without pulling in the entire Aries universe.
  When DIDComm spec is published we would love to consider a
    message based API that is compatible with it, but we have no
    timeline for when that will be possible.
  Some might argue that this work item should be all that we
    need:

    https://github.com/w3c-ccg/vc-http-api

  However, it lacks the appropriate level of contribution and
    support for Holders and Verifiable Presentations.
  Simply put, there is no consensus on the work item scope, and
    no UCR, and there is very little contribution to it.
  It does not support https://w3c-ccg.github.io/vp-request-spec.
  We aim to be compatible with BOTH the vc-http-api AND the
    vp-request-spec, but we can't afford to be blocked by poor
    contribution to them, and we can't afford to wait for DIDComm to
    mature enough to be a better starting building block.
  We need a solution that works over HTTP today.

    What is new in your approach and why do you think it will be
      successful?

  We wrote the first version of the vc-http-api test suite, and
    are the number 1 contributor to the work item:
  https://github.com/w3c-ccg/vc-http-api/graphs/contributors
  We have a well defined use case, and narrow set of
    requirements, and the skills and software necessary to execute
    on it.
  We have a spec, implementation and test suite that already
    shows our approach works, and which are 100% compatible with the
    features the vc-http-api and vp-request-spec have decided to
    support.
  We can't convince the vc-http-api CODEOWNERs to support
    Verifiable Presentations, they should not be able to block us
    from doing so, we need a separate work item to make progress :)

    How are you involving participants from multiple skill sets
      and global locations in this work item? (Skill sets:
      technical, design, product, marketing, anthropological, and
      UX. Global locations: the Americas, APAC, Europe, Middle
      East.)

  We're using the tools available to us from the W3C CCG,
    including JITSI meeting software and GitHub.

    What actions are you taking to make this work item
      accessible to a non-technical audience?

  We're having regular calls where anyone can join and ask
    questions. However, this work item is specifically a technical
    work item, API Spec, Test Suite, and Sample Implementation.
  We are not seeking UCR / Design / Product feedback.
  —
    You are receiving this because you are subscribed to this
    thread.
    Reply to this email directly, view it on GitHub, or unsubscribe.
  [

{ @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/w3c-ccg/community/issues/191", "url": "https://github.com/w3c-ccg/community/issues/191", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

OR13 commented 3 years ago

@David-Chadwick yes, I plan to run / contribute to such an IIW session, I have worked on a lot of these specs and they are all missing something critical, sadly we can't seem to agree on which parts in which specs.

At the end of the day, I think this is mostly a consequence of building data models and protocols without a use case.... certainly the recent https://github.com/digitalbazaar/vaccination-certificate-test-suite highlights how important a shared use case it to demonstrating technical interoperability.

David-Chadwick commented 3 years ago 
Interestingly the lack of a use case is not the issue I am
  facing, because I assume that the client/wallet/user/requestor
  wants to access a resource (any resource, it does not really
  matter) at the service provider. This is the common abstraction of
  all use cases. The SP must return its policy (for this resource)
  to the requestor, and get a VP back that matches its policy for
  this resource. The requestor can then be given access to the
  resource.

The problem I am facing is that the SP does not know anything
  about the wallet, what policy formats it accepts, what formatted
  VP it will return, using what crypto, what schemas etc. These are
  the issues I am trying to solve in my design, using a Simple
  Universal Verifier

Kind regards
David

On 12/04/2021 21:56, Orie Steele wrote:

  @David-Chadwick yes, I plan to run
    / contribute to such an IIW session, I have worked on a lot of
    these specs and they are all missing something critical, sadly
    we can't seem to agree on which parts in which specs.
  At the end of the day, I think this is mostly a consequence of
    building data models and protocols without a use case....
    certainly the recent https://github.com/digitalbazaar/vaccination-certificate-test-suite
    highlights how important a shared use case it to demonstrating
    technical interoperability.
  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub, or unsubscribe.
  [

{ @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/w3c-ccg/community/issues/191#issuecomment-818231064", "url": "https://github.com/w3c-ccg/community/issues/191#issuecomment-818231064", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

OR13 commented 3 years ago

@David-Chadwick It sounds like you may be looking for:

We've also ben working on a standard JSON model for "AuthorizedFlows" and "AuthorizedPresenters"...

They are really rough, but generally work for simple allow-list oriented policies...

Obviously policy management is its own source of pain.

I would recommend taking a look at: https://www.openpolicyagent.org/

At some point I am planning to write a universal wallet plugin for it.

OS

TallTed commented 3 years ago

@OR13

consequence of building data models and protocols without a use case

and yet

We are not seeking UCR / Design / Product feedback.

I wonder whether it makes more sense to start by developing a UCR, and then proceed to develop the API(s) necessary to satisfy those requirements which have not been and/or apparently cannot be stated clearly enough that anyone not directly involved with your team(s) understands your needs?

I wonder, too, whether you might review your initial post here, and try to remove the combative tone that is only slightly blunted by an emoticon that feels more like a typo?

TallTed commented 3 years ago

@David-Chadwick -- Please edit your emailed responses, removing the fully-quoted previous post(s), as they make it difficult to digest the discussion thread through the github website.

OR13 commented 3 years ago

@TallTed I don't see forking or working in parallel when consensus can't be achieved as problematic.

Thanks for the typo correction! And for your feedback on this and many other issues, I tried to tone it down a bit, but my frustration is clearly showing... I think it's ok to be frustrated and to let it motivate progress : ) Its part of what lead folks to create VCs and DIDs.

You can read more about our use case driven open standards and interoperability work here:

We're just one of many companies working in the open on supply chain traceability and security.

If you are looking for more data model related use cases, checkout https://github.com/w3c-ccg/traceability-vocab

We obviously need an API to exchange these data models just as much as we need the data models.

David-Chadwick commented 3 years ago

@David-Chadwick It sounds like you may be looking for:

* https://github.com/decentralized-identity/presentation-exchange

We've also ben working on a standard JSON model for "AuthorizedFlows" and "AuthorizedPresenters"...

They are really rough, but generally work for simple allow-list oriented policies...

Obviously policy management is its own source of pain.

I would recommend taking a look at: https://www.openpolicyagent.org/

At some point I am planning to write a universal wallet plugin for it.

OS

Not really. I am familiar with Presentation Exchange. I am working at level of abstraction above this. Presentation exchange is just one of many policy formats that might be used in the exchange, and it does not solve my issues. For example, even if everyone uses PE, and the SP says it wants a VC for a particular schema, and the user returns a JWT when the SP is expecting a ZKP exchange, then PE does not help one bit. Not even if the SP sets PE to mandate ZKPs. Then you have no exchange as the user cannot fulfil this

OR13 commented 3 years ago

@David-Chadwick this is now fairly off topic for the current work item proposal, however:

For example, even if everyone uses PE, and the SP says it wants a VC for a particular schema, and the user returns a JWT when the SP is expecting a ZKP exchange, then PE does not help one bit.

https://identity.foundation/presentation-exchange/#claim-format-designations

I believe PE spec intended to allow folks to do what you want... whether its possible or not is another matter.

David-Chadwick commented 3 years ago

Sorry I did not mean to close it!

David-Chadwick commented 3 years ago

I believe PE spec intended to allow folks to do what you want... whether its possible or not is another matter.

I dont believe it solves the problem, since the SP can ask for a format that the wallet cannot provide

TallTed commented 3 years ago

@OR13

my frustration is clearly showing... I think it's ok to be frustrated and to let it motivate progress : ) Its part of what lead folks to create VCs and DIDs.

Some venting of frustration motivates progress. Other venting stifles it. It can be hard to tell which kind of venting is going on, in the moment. I therefore urge caution in that venting.

Note that the VCWG took some years to complete its work. Note that the DID WG arguably took several more years than the VCWG (certainly, if you track back to the origins of the DID WG, as opposed to its official instantiation) just to reach CR on DID Core -- which hasn't made it to PR/TR yet, and is far from the entirety of what needs to be finished, for DIDs to really be considered to be done.

You're frustrated and demanding that consensus be reached in months, if not weeks, on things which haven't been clearly described (as you've noted yourself: there is no UCR), never mind well understood, by people other than those who could have authored those (still missing) clear descriptions.

You're demanding this immediate consensus because of what I can only guess are commercial pressures, which would more commonly result in a Community Submission which might be authored by a single commercial entity, or even an "do it our way or don't talk to us" stake in the ground of a private spec, or even more audaciously, a "use our tools if you want to do this".

Community development of standards is SLOW when there hasn't been a lot of experimentation in the area where the standards are desired. This slowness is necessary because poorly understood things lead to poorly designed standards which fail to be taken up by the community, or, possibly worse, fail in use when they are taken up, leading to backlash against the thing which was supposedly going to be of community benefit.

If you really want a successful standard to exit from the process, where multiple commercial entities and products will interoperate to do whatever it is that you want to do, then you must take a (few thousand) breath(s), and let the process do its job -- even if that takes months or years longer than you wish it would.

OR13 commented 3 years ago

@TallTed thanks for the feedback.

I approach standards with more of an open source developer attitude than a spec editor one, and it shows in our approach.

I think when there are 0 ways to do something, nobody should block going from 0 to 1.

when there is 1, there should be 2 or 3 or 5... and when there are enough to evaluate which is best, the community and market should apply pressure to consolidate.

As I mentioned at the top of the issue, I look forward to that harmonizing phase, we have seen it with things like the io.js node.js issue.

I am a fan of release early, release often, ship breaking changes when they are necessary, and fork when it accelerates progress.

I also think there is nothing wrong with wanting to move very slowly and cautiously, and the pace a group moves is a function of its effectiveness.

For example, Group 1 might merge pull requests in 1 day, and then open a new PR to make corrections a day later.

Group 2 might merge pull requests in 1 month, and only after they were perfect.

Depending on the level of maturing, Group 2 might be a better approach.

In my opinion, Group 2 work style is not appropriate for the case where 0 solutions exist... we don't need to force Group 2 to change, we can just make a new Group 1 that allows participants that want to move a bit faster on CCG work items to do so.

He who receives an idea from me, receives instruction himself without lessening mine; as he who lites his taper at mine, receives light without darkening me.

I don't think we need to all huddle around a single candle :)

TallTed commented 3 years ago

Standards are not FOSS (Free and/or Open Source Software), nor even CCSS (Commercial and/or Closed Source Software).

Standards can help define and support an ecosystem for FOSS and/or CCSS, but the development of those standards does not typically work out very well in the kind of free-for-all you describe -- though such a free-for-all may work fine for subsequent development of FOSS/CCSS based on those standards, once the standards are developed.

dhh1128 commented 3 years ago

  1. I disagree with the need. Framing credential exchange as an HTTP API will reinforce the client-server paradigm in which clients are digital serfs and organizations (the only entities that maintain 24x7 access on the internet) reinforce their power as arbiters of user data. I DO NOT disagree with exposing HTTP-based credential exchange; what I disagree with is framing the problem as an HTTP problem. What we need instead is a way to exchange credentials over HTTP such that the mechanism is not limited to HTTP, does not depend on existing HTTP constructs like TLS-based and session-based security, and is usable by ordinary people who want to issue. What I am deeply concerned about is building a standard that is only usable by corporate issuers, and thereby sucking all the air out of the ecosystem that is needed to help digitally disenfranchised people. The money in SSI comes from orgs; if we follow the money and give them an HTTP-only standard, they will all go away and say "problem solved", and there will never be any funding for a truly self-sovereign solution that serves both institutions and individuals.

  2. I also disagree with the characterization of DIDComm. DIDComm is quite usable with HTTP. Yes, DIDComm v2 is not yet baked -- but it has largely undone all the Hyperledger Aries entanglements that Orie mentioned, and the spec is maturing nicely. What's more, there is already a DIDComm v1 version of credential exchange that supports DIF presentation exchange and arbitrary credential and presentation formats; recasting it for complete Hyperledger independence in DIDComm v2 is trivial (an afternoon of work), not a major project. And this protocol has a large set of shipping implementations. Starting over on something that is even newer than DIDComm v2 is not a way to get done faster; it's a way to get done slower, and to jerk the rug out from under a standard that the W3C is not developing. It fragments the ecosystem and is the opposite of an interoperability move the CCG should be sponsoring.

OR13 commented 3 years ago

@dhh1128 have you see this:

https://specs.bloom.co/wallet-and-credential-interactions

It's essentially what we want but is yet another way to do exchange, and it builds on the DIF Presentation Exchange Spec and Credential Manifest Specs.

If I could see a similar path to using DIDComm over http, it would help greatly.

We're not trying to reinvent DIDComm, at this point that would take years, given how big it has gotten.

For the record, we agree that HTTP is not the only transport for VPs.... but we need a solution that works over HTTP today.

wyc commented 3 years ago

Hi, based on the weekly call on 4/27, there seems to be support for this item if it were named to indicate a broader scope than just an API, more along the lines of:

@OR13 are you still open to making this change? If so, I believe that there would be no remaining objections to this work item moving forward.

cc @vsnt

OR13 commented 3 years ago

Traceability Interoperability Profile works for me. @wyc

wyc commented 3 years ago

I believe that’s in line with the suggestions on the weekly call, so at this point I don’t think there are any more objections to this, which means it should proceed.

cc @vsnt and some participants from that call for any additional feedback: @msporny @TallTed @mprorock @dmitrizagidulin @bumblefudge

https://w3c-ccg.github.io/meetings/2021-04-27/#topic-4

vsnt commented 3 years ago

Sounds good to me. I have added it to the agenda for tomorrow's meeting (Tuesday) to allow for any objections.

mprorock commented 3 years ago

big +1 from mesur for "Traceability Interoperability Profile"

TallTed commented 3 years ago

I'm sure there will be some shorthand nickname, as "Traceability Interoperability Profile" is quite a mouthful, but it does a better job of communicating what's actually being worked on.

vsnt commented 3 years ago

There were no objections to making this a formal work item at the 5/4/21 meeting. @wyc can you activate the work item repo &ct: https://w3c-ccg.github.io/create_work_item.html. Thanks.

wyc commented 3 years ago

Confirmed on the weekly call that the name is to be traceability-interop.

wyc commented 3 years ago

I've created https://github.com/w3c-ccg/traceability-interop and will be adding this work item to the list. Thanks for the interest, perseverance, and openness to feedback.