Specification of APIs or protocols is out of scope #43
Conversation
|
I think this is going to be controversial and we'll need to discuss this a bit further. One of the reasons we left this in scope was to allow for the ability to mention in non-normative ways how VC HTTP API/OIDC4SSI protocols may work especially for things like mDL integration to issue/hold/verify VCs and what the impact of those systems may have on the data model. The expectation that we completely leave these things out of scope will need to be dug into further to see how we want to scope this statement a bit better. |
There was a problem hiding this comment.
-1, this is not what had consensus in the VC WG.
The group, having standardized a data model in 2019, clearly wanted to be able to start laying the groundwork for protocols that utilize VCs. There is active work in this space (VC API, WACI/PeX, OIDC CP, DIDCommv2, etc.) (and has been for years) with real demonstrable interop.
|
@kdenhartog what do you mean by "mDL integration to issue/hold/verify VCs" ? ISO mDL and W3C VCs are separate data models right now. |
|
@msporny what do you mean by "laying the groundwork for protocols"? the protocols you mention are being worked on in their respective SDOs and WGs, and it's in scope of those protocol specifications to spec out how vc-data-model can be used in those protocols. Not the other way around. Saying protocols are in-scope implies defining how those protocols work and is very different from being able to "mention these protocols in a non-normative way". Non-normatively mentioning them should be possible without explicitly saying protocols are in-scope (@iherman please correct me if that is not the case). and if that is not the case, it should be stated more explicitly that "Non-normatively mentioning protocols is in scope". I just wanted to say thank you for revisiting few items that you might have discussed previously. Microsoft has joined the VC working group only last week. Not being on the WG calls previously, we have not been able to closely track discussions around the charter, but will be participating more actively. |
|
I fully support being able to discuss how protocols will use our outputs. Note that the PR explicitly contains the text "(although implications for APIs and protocols of data model and data integrity choices made MAY be discussed)". But this working group shouldn't be the place that these protocols are actually defined. |
That statement is correct. |
Sorry, I meant the mobile driver's license protocols such as the protocols they use to exchange the mDocs that are coming out of ISO WGs. Not necessarily the mDoc data models. Last I remember there was a willingness to see closer alignment between the VC data model and that body of work happening over at ISO. |
|
Thank you, @kdenhartog. |
|
From my standpoint
Can we agree on the above? |
No, we cannot, specifically because at least seven vendors in this group are already working on a transport protocol for VCs called the Verifiable Credential API: https://w3c-ccg.github.io/vc-api/ It is expected that, within the lifetime of the VCWG, that the CCG will likely request that the VC WG publish the VC API as a Note (to prepare for the next rechartering of the WG to put that work directly in scope). While it is true that there are other groups working on protocols for moving VCs around (and they're free to do that and we should liaise with them), it is the VCWG that is the authority on the data model and the protocols that it wants under its purview. The VC API is such an API, and for the reasons listed above, we must be able to discuss it in depth in the group as it matures in CCG, and we must be able to publish it as a Note during the lifetime of the VCWG (with the expectation that a recharter will put it firmly in scope for the next rechartering of the WG (VCWG 3.0). |
|
Wait, so does publishing a note (which as I understand it is completely non-normative) mean that we need this work to be explicitly in scope? My understanding was that because that work was being done in a note, non-normative changes can be made without explicitly mentioning it in scope and by placing it out of scope like this text is doing, all we're saying is that we won't be normatively defining protocols in any particular way which is what it seems to be agreed upon previously and what I understood @Sakurann second statement to mean. It seems like the argument being made @msporny is that you want this in scope because you want to be able to define a note, but it's not clear to me why that's needed. |
It's needed because a process trick that some organizations that have been playing this game for a while use is that if something is not mentioned as a deliverable in a charter, the blocking organization states that the work was never contemplated, and discussion on that particular topic should halt immediately (because it's out of scope for the charter), much less doing anything that results in publishing a NOTE on the topic. If the group wants to publish a particular NOTE, it should be very clear about it, because groups that have not been clear about it in the past have found W3C Members in the group objecting to the NOTE based on it not being mentioned in the charter at all. To be exceedingly clear -- seven vendors in the VCWG are implementing a VC API that exists in the CCG and is planned to be handed over to the VCWG 2.0 group. We know this. We should explicitly state that so there can be no shennanigans later on about "APIs being out of scope", which is one valid interpretation of this PR (attempting to put publishing the VC API as a NOTE as out of scope). |
At least as I understand it, the CCG can publish its own non-normative notes itself. We don't have to do that for them. We could just as well reference a note they publish if we do another recharter at some point in the future. |
|
The issue was discussed in a meeting on 2022-01-26
View the transcript7.5. Protocols and APIs should remain out of scope (issue vc-wg-charter#24)See github issue vc-wg-charter#24. See github pull request vc-wg-charter#43. Brent Zundel: Issue 24. Originally raised by Mike, before he was even in the group. Recently had more conversation. Opening up the floor. Michael Jones: Thank you. The point was made on the issue that there are a lot of protocols using the spec, which is great, that's a form of adoption, that's happened without us doing any of the protocols.. Orie Steele: I agree with everything Mike just said. Michael Prorock: Quick option, having a note similar to an implementation guide, etc., that if you want to exchange this over REST, you might want to use this... Maybe one way to approach it, I think in line with Mike Jones's comment. Michael Jones: I agree. Kyle Den Hartog: General understanding was to leave this non-normative.. Brent Zundel: Thank you all. Please continue the conversation in the PR. Michael Jones: Thank you for welcoming us.. |
No, the CCG has no capability of publishing a W3C NOTE, only W3C WGs may publish NOTEs. The point of publishing as a VCWG NOTE is to signal, very clearly, that we intend to standardize the NOTE and to include it in a re-charter. Signalling now, instead of 2 years from now, is the appropriate thing to do given that we already have 7 vendors that have implemented the VC API and interop work on will continue this year at a rapid pace. |
|
The purpose of this charter PR is to remove the WG's ability to discuss or publish a note regarding this particular API (of which I am one of the implementers)... This PR cannot be accepted as is (removal is unacceptable to me)... However, the lack of definition regard what the WG is planning to do with this api (the vc-api incubated at the W3C CCG)... is also unacceptable, and I might be in favor of this PR depending on how good of a job we can do at defining our intentions ahead of approving the new charter. We need to be clearer than simply pointing to the CCG Work item, because the WG could decide to publish a note that started with the work item, and then completely rewrote it (say only to support JSON-LD or only JWT, or only AnonCreds, etc...) I think we need to a see a PR that defines what the WG attempts to do with the work item.... and if that PR can't gain consensus this PR should be merged. |
|
This is exactly why API and protocols should be out of scope as there are already protocols that carry VCs. What is the exact interoperability issue you are trying to solve? An API is not a protocol, what is the exact interoperability issue requiring a API? What are the use cases requiring a n API and protocol? What about the protocols that are already carrying VC? |
|
How about we add the following sentence in the potential non-normative deliverables section?
We want to make it clear that a) we are not defining new APIs/protocols or making modifications to the existing once, while b) we are allowed to discuss how best to design data model/data integrity taking existing APIs/protocols into account. Currently, the data model covers the range of use-cases wide enough, choosing only one API/protocol would be very limiting. |
These are all excellent questions, and the charter should be constructed to ensure that they are answerable. This PR leads to a world where that might not happen, which is why it cannot be accepted.
Big +1 ... but... I am not sure this PR is helping with that as much as it is potentially hurting that. As a developer and a standards person, I prefer to retain the tools we need to protect the standard and refine it. The charter gives us a toolbox... we don't need to use all the tools... but i'm a -1 to removing tools out of the toolbox that might help us make the case for data model changes that are "discovered" from WG notes or other sources.. and we won't make those discoveries if they are out of scope. The WG still has to agree to publish a note... The WG might agree that not publishing anything on the subject of protocols or APIs is wise... and they are more likely to come to that conclusion with a refinement to the charter position on this topic. If you can't trust the WG to make good decisions, objecting to charter scope is a valid move... but you should just say that directly. This PR just injects risk. Instead we should be injecting refinement. |
|
My concern is that the discussion in this PR should happen by the to-be-chartered WG, rather than here.
Totally disagree as its too late at this point, people need to understand what is in scope at the time of chartering so they can decide if their IPR is at stake and if they have the ability to contribute. A discussion can happen after the initial charter is adopted and a re-charter can happen if desired by the WG, and the W3C process.
|
|
I find the email replies very distracting, and making it hard to tell "who is saying what". |
I don't agree with you... but only regarding your assertion regarding "non-normative material". |
|
Non-normative material confuses readers but some people do that on purpose.
|
|
OH, well so do I
From: Orie Steele ***@***.***>
Sent: Monday, January 31, 2022 8:24 AM
To: w3c/vc-wg-charter ***@***.***>
Cc: Anthony Nadalin ***@***.***>; Comment ***@***.***>
Subject: Re: [w3c/vc-wg-charter] Specification of APIs or protocols is out of scope (PR #43)
I find the email replies very distracting, and making it hard to tell "who is saying what".
—
Reply to this email directly, view it on GitHub <#43 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4R4YZUZD3UNB2KQ7W6RS3UY2ZRPANCNFSM5MOEM2GQ> .
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .
You are receiving this because you commented. <https://github.com/notifications/beacon/AB4R4Y4OYW6D4AZODCBHA4LUY2ZRPA5CNFSM5MOEM2G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHUTO3BA.gif> Message ID: ***@***.*** ***@***.***> >
|
The W3C Patent Policy, and the resulting IPR disclosure requirement, applies to Recommendation-track documents only. I think there is a consensus on this thread that no API discussion would take place in a Recommendation-track document; the question is whether we would leave the door open for Note-track documents on API-s or whether we want to explicitly forbid that, too. I.e., it may be better not to bring IPR issues into the discussion. |
|
The W3C patent policy applies to the WG, so when you join the WG you consent to a RF patent policy.
As a condition of participating in a Working Group, each participant (W3C Members, W3C Team members, invited experts, and members of the public) shall agree to make available under W3C RF licensing requirements<https://www.w3.org/Consortium/Patent-Policy-20040205/#def-RF> any Essential Claims<https://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential> related to the work of that particular Working Group. This requirement includes Essential Claims that the participant owns and any that the participant has the right to license without obligation of payment or other consideration to an unrelated third party. With the exception of the provisions of section 4 below, W3C RF licensing obligations made concerning the work the particular Working Group and described in this policy are binding on participants for the life of the patents in question and encumber the patents containing Essential Claims<https://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential>, regardless of changes in participation status or W3C Membership.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Ivan Herman ***@***.***>
Sent: Tuesday, February 1, 2022 12:41:21 AM
To: w3c/vc-wg-charter ***@***.***>
Cc: Anthony Nadalin ***@***.***>; Mention ***@***.***>
Subject: Re: [w3c/vc-wg-charter] Specification of APIs or protocols is out of scope (PR #43)
Totally disagree as its too late at this point, people need to understand what is in scope at the time of chartering so they can decide if their IPR is at stake and if they have the ability to contribute.
The W3C Patent Policy, and the resulting IPR disclosure requirement, applies to Recommendation-track documents only. I think there is a consensus on this thread that no API discussion would take place in a Recommendation-track document; the question is whether we would leave the door open for Note-track documents on API-s or whether we want to explicitly forbid that, too. I.e., it may be better not to bring IPR issues into the discussion.
—
Reply to this email directly, view it on GitHub<#43 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4Y7JCVD7MJ4B36SHODTUY6MDDANCNFSM5MOEM2GQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
True. But, if you follow up the essential claim link which defines what it is, it says:
(Emphasis is mine.) But I would propose not to continue down that line. I do not think the formal IPR issue is the really dominant argument pro or con in this thread, so we are side-tracking. And, to be clear: IANAL... |
|
Not side tracking at all as IPR is a key issue on what is in a charter or not and what is discussed in the WG thus the decorations when you join the WG
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Ivan Herman ***@***.***>
Sent: Tuesday, February 1, 2022 6:07:40 AM
To: w3c/vc-wg-charter ***@***.***>
Cc: Anthony Nadalin ***@***.***>; Mention ***@***.***>
Subject: Re: [w3c/vc-wg-charter] Specification of APIs or protocols is out of scope (PR #43)
True. But, if you follow up the essential claim link<https://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential> which defines what it is, it says:
"Essential Claims" shall mean all claims in any patent or patent application in any jurisdiction in the world that would necessarily be infringed by implementation of the Recommendation. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the normative portions of the Recommendation. Existence of a non-infringing alternative shall be judged based on the state of the art at the time the specification becomes a Recommendation.
(Emphasis is mine.)
But I would propose not to continue down that line. I do not think the formal IPR issue is the really dominant argument pro or con in this thread, so we are side-tracking.
And, to be clear: IANAL...
—
Reply to this email directly, view it on GitHub<#43 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4YZA2GEVHPVY2AZUVADUY7SKZANCNFSM5MOEM2GQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This is borderline microaggression : ) Please don't assume that folks working in good faith to provide clarity regarding the data model are acting in bad faith. I would like to discuss and comment on at least these 2 items in a non normative manner:
I won't accept blanket language in the charter that obstructs this objective. WG Notes are essential to keeping the TR clear, and focused on the topics of highest consensus. WG Notes provide for better answers to contentions issues where consensus may have obstructed clarity or "split the difference"... The V1 Data Model suffers from this in numerous places, and the proposal to use more WG Notes this time around addresses these weaknesses head on and makes sense to me. I appreciate the desire to limit the charter of the WG and its outputs, and I think it is helpful to provide more detail on each item so that work is effectively constrained and folks like yourself understand what you are signing up for when approving the charter and joining the WG to assist with the work. |
|
If you're a truly after interoperability then the definition of the operations and what is performed is key, not the definition of an API.
So I'm against any API discussions, protocol discussions In any of the material that work group produces.
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Mike Prorock ***@***.***>
Sent: Tuesday, February 1, 2022 8:14:52 AM
To: w3c/vc-wg-charter ***@***.***>
Cc: Anthony Nadalin ***@***.***>; Mention ***@***.***>
Subject: Re: [w3c/vc-wg-charter] Specification of APIs or protocols is out of scope (PR #43)
@mprorock commented on this pull request.
________________________________
In index.html<#43 (comment)>:
@@ -159,6 +159,7 @@ <h3 id="out-of-scope">Out of Scope</h3>
<ul class="out-of-scope">
<li>The mandate of any specific style of supporting infrastructure (such as a DLT) for a verifiable credentials ecosystem</li>
<li>The specification of new cryptographic primitives</li>
+ <li>The specification of APIs or protocols (although implications for APIs and protocols of data model and data integrity choices made MAY be discussed)</li>
I am also ok with this language - key thing is to clarify that what we are after is a defined API for the exchange of VCs as defined by the data model, as well as API definitions where appropriate for handling common operations on / with VCs as defined in the data models so that those items can be handled consistently between multiple vendors.
—
Reply to this email directly, view it on GitHub<#43 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4YZRJII6WICIHCKGJATUZABHZANCNFSM5MOEM2GQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
To be honest, my head is spinning a little so I'll try not to add noise to the channel or slow down consensus on the proper scope of this working group, but I will simply note that Spruce has invested a lot of very finite resources in building against the VC-API and I personally (with support from Spherity GmbH) have invested a lot of time in supporting its specification effort and tracking its relationship to (and potential compatibility with) other protocols. I am sympathetic to wanting APIs definitively out of scope, but I also feel this particular API was painstakingly assembled out in the open by a diverse set of VC implementers, with different goals and expectations than might be assumed. It has felt, at times, as though the primary purpose of the effort was to prototype and experiment so as to identify interoperability issues and unspoken assumptions that might feed back into this very WG. Rarely has it felt as though the intention were to produce a standards-track or production-ready API fit for a commercial ecosystem. I like Manu's suggestion that it be kept in scope for discussion as a prototype or experiment and with no explicit or implicit promise that it become a major protocol to compete with the others mentioned. If anything, it could be useful as a reference if this WG wanted to write an implementation guide or an architecture document for helping people do an apples-to-apples assessment of the protocols already looming on the market horizon. I do not think it would make sense to move the VC-API work into this WG or into any other W3C or IETF WG, except as an "input document". Sorry that I am too junior in these matters to translate this opinion into a PR or a change request, but I mostly wanted to leave a testimonial as someone who's been following that spec very closely at CCG. |
|
You mix API with protocol. These are totally two separate entities. Once again, for IPR purposes, it needs to be clearly spelled out in the charter whether it's in scope or out of scope as this will make a big difference for companies wanting to participate or not. So I'm not in favor a Manu's proposal at all Is it does not clearly state intent.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Bumblefudge ***@***.***>
Sent: Wednesday, February 2, 2022 8:08:17 AM
To: w3c/vc-wg-charter ***@***.***>
Cc: Anthony Nadalin ***@***.***>; Mention ***@***.***>
Subject: Re: [w3c/vc-wg-charter] Specification of APIs or protocols is out of scope (PR #43)
To be honest, my head is spinning a little so I'll try not to add noise to the channel or slow down consensus on the proper scope of this working group, but I will simply note that Spruce has invested a lot of very finite resources in building against the VC-API and I personally (with support from Spherity GmbH) have invested a lot of time in supporting its specification effort and tracking its relationship to (and potential compatibility with) other protocols.
I am sympathetic to wanting APIs definitively out of scope, but I also feel this particular API was painstakingly assembled out in the open by a diverse set of VC implementers, with different goals and expectations than might be assumed. It has felt, at times, as though the primary purpose of the effort was to prototype and experiment so as to identify interoperability issues and unspoken assumptions that might feed back into this very WG. Rarely has it felt as though the intention were to produce a standards-track or production-ready API fit for a commercial ecosystem.
I like Manu's suggestion that it be kept in scope for discussion as a prototype or experiment and with no explicit or implicit promise that it become a major protocol to compete with the others mentioned. If anything, it could be useful as a reference if this WG wanted to write an implementation guide or an architecture document for helping people do an apples-to-apples assessment of the protocols already looming on the market horizon. I do not think it would make sense to move the VC-API work into this WG or into any other W3C or IETF WG, except as an "input document". Sorry that I am too junior in these matters to translate this opinion into a PR or a change request, but I mostly wanted to leave a testimonial as someone who's been following that spec very closely at CCG.
—
Reply to this email directly, view it on GitHub<#43 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4YZLCVBU6DQZLEMHBZLUZFJHDANCNFSM5MOEM2GQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I have re-read my comment and can confirm that I meant "API" and "protocol" each time I used either word. I'd be glad to hear on the call how the relationship between those two separate things can be nuanced, as I am admittedly junior in this regard. |
|
The issue was discussed in a meeting on 2022-02-02
View the transcript5.2. Protocols and APIs should remain out of scope (issue vc-wg-charter#24)See github issue vc-wg-charter#24. Brent Zundel: Orie, if there is further refinement needed, we'd like to see a PR.
See github pull request vc-wg-charter#43. Brent Zundel: This issue (and PR) has received quite a lot of attention lately.. See github pull request vc-wg-charter#66. Brent Zundel: MikeJ, can you give us a status update?. Michael Jones: This has been an active discussion, which is great... in summary, we do have consensus to not do normative protocol or API work..
Michael Jones: There is an interplay where working on both can be helpful. That said, specifying non-normative API/deliverables would be a distraction. I did hear from Manu that WG has good track record of keeping their focus. We might also want to look at MikeP's PR..
Michael Jones: His PR does says not to do normative API work, removes normative API deliverable, but then adds a bunch of other stuff..
Michael Jones: Orie said things couldn't be done in a day, but that could be a path to be done soon..
Kyle Den Hartog: I saw MikeP's PR -- agree with that direction. One of the most difficult is that people don't understand which protocols should be used when/where. This is the non-normative aspect that would be useful. One of the things that VC API comes into play is because it's a CCG work item, having it move to NOTE gives it a home and can point to it more easily.. Michael Prorock: I wanted to clarify on the PR, MikeJ and Kyle got it well -- we clarify that we don't want to do normative protocol work, but from non-normative side, we don't want to box ourselves from talking about guidance to provide, critical from adoption and messaging standpoint. That's why I want to include those non-normative protocol items.. Orie Steele: I agree with MikeP, as much as we want to get charter out to AC -- there are other things important, data model work here, w/o protocol to move things around is terrible and useless. We want to drive attention/traffic/support to where that work is happening. I need that work to be done sooner than I need the v2 charter sent to AC mailing list. We need those OpenID Connect drafts to be further along. We need a standard for moving that data model around. we won't be doing that work here, we want people to contribute, use what they have, be supportive of OIDC, IETF, etc.. Manu Sporny: We do have consensus on not doing protocol work in a normative fashion. That's true. There's a corollary to that, which is -- as long as we can do work around describing protocols and how developers use them and all the things Mike Prorock and Orie have been outlining..
Manu Sporny: We do not have consensus on not talking about protocol at all. What we don't have consensus on is not being able to talk about the VC-API or publishing it as a note..
Manu Sporny: We should go forward with those things we have consensus on, but we should not overlook on the statements from Mike Prorock's PR... the only objector, I believe, is Mike Jones -- on the non-normative items from Mike Prorock. There's a fairly large group of people that want to be able to talk about this non-normatively and publish NOTEs..
Michael Jones: To Manu's point, he said that there are those that don't want us to talk about protocols at all -- I don't know who those people are. Using the audience example, data structure and protocol, important to understand relationship between the two. There is substantial objection to specifying protocols/APIs in this group. Fine to reference specs/discussions elsewhere, but there is a bright line between specifying protocol and just talking abut protocol work happening elsewhere..
Michael Jones: We defined JWTs w/o protocols, we knew they would use it, some of them in OAuth, data formats stands by itself and is used by all kinds of things, secured caller ID, which I never imagined, but that's great..
Kyle Den Hartog: Rhetorical question -- do we expect that the discussion of how data model is moved along many different protocols that we should be able to speak about wrt. parehtentical. If I issue VC around OpenID Connect, but want to present via VC API/DIDComm, if there are implications, how are we able to discuss those sorts of things w/o documents? CCG is considered referenceable, but is that good enough?.
Michael Jones: We can talk about anything we want..
Joe Andrieu: I don't understand pushback against non-normative documents..
Brent Zundel: The question comes down to -- explicitly list intended non-normative notes that should be published concerning APIs/protocols. That's the remaining question/disagreement.. |
There was a problem hiding this comment.
My understanding has always been that the first VC WG would focus exclusively on the data model, and then the next VC WG would also begin some work on APIs and protocols. Hasn't that always been the plan all along? What use is the data model without APIs and protocols?
Anyway, adoption of VCs is now definitely increasing to a point where work on APIs and protocols is necessary in order to enable interoperability between vendors, use cases, jurisdictions, etc.
The main desire in #24 seems to be "leaving choices of platform APIs and use in communication protocols to those building and deploying systems using the data model".
But I don't see a contradiction here. If the VC WG publishes one or more notes, then that doesn't really preclude others from still choosing or developing whatever APIs or protocols they want on top of the data model?
|
What use is the data model without APIs and protocols?
All you have to do it look at the adoption of JWT and see that these are ubiquitous, no API or Protocol, very successful and way far more deployments than VCs. Ver limiting to define an API and Protocol.
Anyway, adoption of VCs is now definitely increasing to a point where work on APIs and protocols is necessary in order to enable interoperability between vendors, use cases, jurisdictions, etc.
Please give the use case for requirement to define an API and Protocol? If VCs are not interoperable then there is something wrong with the data model and maybe VCs should have reached Recommendation status if these are not interoperable. There are lots of transports that can carry the VC data model one way or another, so can you explain the issue?
Reply to this email directly, view it on GitHub <#43 (review)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4R4Y7HZ7OIVCMX4QCJPADUZLOJ5ANCNFSM5MOEM2GQ> .
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AB4R4YYS66WULVX7UIZVIWTUZLOJ5A5CNFSM5MOEM2G2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOGP7RZMQ.gif> Message ID: ***@***.*** ***@***.***> >
|
|
I think some of the readers are confusing the word "API" to mean "Browser API", instead of what's intended "HTTP API"/"HTTP protocol". Just noting that, not that it helps
I understand what is being proposed but this brings up the issue that you have excluded and browser API, maybe the best venue for what you are proposing is IETF if you are not also considering a browser API
|
Yes interoperability on the VC data model level exists today of course, but that's a very limited type of interoperability I think? I can copy and paste a VC or a JWT and send them via email, but that's not very useful by itself. JWTs are also mostly useless if you don't have an API or protocol for moving them around.
Yes and I think it would be useful to take one or more of those transports and publish them as a note? |
|
Sorry I chair Webauthn and it's not what I would consider HTTP at all, it's a Java Script browser API. I reiterate that any http api or protocol should be done in IETF not here.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Orie Steele ***@***.***>
Sent: Friday, February 4, 2022 6:29:04 AM
To: w3c/vc-wg-charter ***@***.***>
Cc: Anthony Nadalin ***@***.***>; Mention ***@***.***>
Subject: Re: [w3c/vc-wg-charter] Specification of APIs or protocols is out of scope (PR #43)
@nadalin<https://github.com/nadalin> W3C has a history of working on HTTP APIs
* https://www.w3.org/TR/activitystreams-core/
* https://www.w3.org/TR/webmention/
* https://www.w3.org/TR/CSP/
* https://www.w3.org/TR/webauthn-2/#sctn-automation-add-virtual-authenticator
—
Reply to this email directly, view it on GitHub<#43 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4YYILWGUVZZQJQND2ALUZPPDBANCNFSM5MOEM2GQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@selfissued This PR originally made two changes:
The first change was added as part of PR #70 since both original goals of this PR have already been accomplished elsewhere, I am closing this PR. |
Fixes #24
Preview | Diff