vc-api
vc-api copied to clipboard
w3c-ccg
Add section on authorization delegation.
I'm still not sure we need either of these things... especially right now.
I agree, I'm trying to hit an acceptable compromise position with this particular PR. We will state that people SHOULD support delegation, but won't have a mechanism w/o GNAP or ZCAPs becoming a thing.
I do think folks think this is eventually where we want to end up, and OAuth 2.0 Client Credentials isn't going to cut it wrt. getting us there. That said, only one implementer seems to want to commit to deploying GNAP at present. Digital Bazaar will eventually support ZCAPs for this API, but certainly not before we support OAuth 2.0 Client Credentials.
PLEASE read the actual definitions of these words as we're using them.
MAY is entirely too loose, as it is too rarely tested (though it often could be, and should register "unsupported" rather than "FAIL").
SHOULD allows you to not do the thing, if you understand the ramifications (which might include interop failure), but pushes hard toward doing the thing.
SHOULD can and should (cough) be tested like a MUST, though results are a bit more complicated because it might need to register "unsupported" or "unimplemented" rather than "FAIL".
MUST is totally rigid, and is often inappropriate for immature tech spaces like various aspects of the DID and VC ecosystems.
@OR13, did @TallTed's explanation sway your requirement? I also agree that we can keep it as SHOULD for now (and change it later if it's causing issues, which I doubt it will).
The delegation issue is more than about a definitions. We need to deal with our intent openly and try to get ahead of the mounting criticism like Phil Sheldrake posted in Project VRM today https://cyber.harvard.edu/lists/arc/projectvrm/2021-09/msg00103.html
Please help me organize a breakout about this for TPAC.
Please consider making delegation a MUST and ignore OAuth altogether.
Also, please consider where and how we can discuss the impact of making Holder a normative concept in our standards. Just because we give someone "consent" by linking control to possession as Holder doesn't mean that consent will not be coercive as with the "shrink wrap licenses" we've grown to despise. https://github.com/w3c-ccg/community/issues/195
Please consider making delegation a MUST and ignore OAuth altogether.
@agropper Implementer hat on here - many of us with actual implementations in the real world have to integrate these solutions into already deployed enterprise environments where OAuth is a given and is the standard. I would respectfully request that you recognize our use cases as valid.
The DHS and commercial supply chain use cases are obviously valid. But the unintended consequences can not be ignored once they are surfaced. The problems with OAuth and OpenID Connect are the unintended consequences that we can no longer ignore.
With all due respect, the cost of integration into already deployed enterprise environments is not a good strategy for dealing with the objections to standards for more efficient digital identification and surveillance. It's the very efficiency of what we're creating that creates the problem. We can't count on regulation or Trust over IP to fix Facebook or runaway data brokerage for profit. As engineers, we need to do our job before they can do theirs.
- Adrian
On Mon, Sep 27, 2021 at 1:55 PM Mike Prorock @.***> wrote:
Please consider making delegation a MUST and ignore OAuth altogether.
@agropper https://github.com/agropper Implementer hat on here - many of us with actual implementations in the real world have to integrate these solutions into already deployed enterprise environments where OAuth is a given and is the standard. I would respectfully request that you recognize our use cases as valid.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/vc-http-api/pull/230#issuecomment-928113405, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YKKUQFKUQ44KGKSCV3UECVZBANCNFSM5D3SPOTA . 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.
Reading the post in the VRM list it seem the basic premise of what is to be avoided is:
- 1 Recognise that legal identity may be useful in a teeny-tiny fraction of contexts
- 2 Enable full KYC for legal identity irrespective of context
I'm typically sympathetic to the VRM vantage point, at least in broad conceptual terms, but I'm left wondering what's the alternative to accepting these premises, short of somehow identifying every valid case for legal identity up front and somehow constraining implementation to only allow for those enumerated situations (which seems infeasible)?
On Mon, Sep 27, 2021 at 1:44 PM Adrian Gropper @.***> wrote:
The delegation issue is more than about a definitions. We need to deal with our intent openly and try to get ahead of the mounting criticism like Phil Sheldrake posted in Project VRM today https://cyber.harvard.edu/lists/arc/projectvrm/2021-09/msg00103.html
Please help me organize a breakout about this for TPAC.
Please consider making delegation a MUST and ignore OAuth altogether.
Also, please consider where and how we can discuss the impact of making Holder a normative concept in our standards. Just because we give someone "consent" by linking control to possession as Holder doesn't mean that consent will not be coercive as with the "shrink wrap licenses" we've grown to despise. w3c-ccg/community#195 https://github.com/w3c-ccg/community/issues/195
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/vc-http-api/pull/230#issuecomment-928105906, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR7T62XRVIQ3FPH5W6CICDUECUPPANCNFSM5D3SPOTA . 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.
-- Daniel "Dazza" Greenwood law.MIT.edu http://law.mit.edu/ & CIVICS.com http://civics.com/ Email: @.***
One way to mitigate the unnecessary or coercive use of "legal" identity is to add cost to its use: https://github.com/w3c/did-use-cases/issues/102#issuecomment-703943437
The unsolved spam problem is a learning opportunity. The cost of processing requests (for stronger identity) must be borne by the requester.
There's no free lunch when it comes to avoiding surveillance capitalism.
On Mon, Sep 27, 2021 at 2:06 PM Dazza Greenwood @.***> wrote:
Reading the post in the VRM list it seem the basic premise of what is to be avoided is:
- 1 Recognise that legal identity may be useful in a teeny-tiny fraction of contexts
- 2 Enable full KYC for legal identity irrespective of context
I'm typically sympathetic to the VRM vantage point, at least in broad conceptual terms, but I'm left wondering what's the alternative to accepting these premises, short of somehow identifying every valid case for legal identity up front and somehow constraining implementation to only allow for those enumerated situations (which seems infeasible)?
On Mon, Sep 27, 2021 at 1:44 PM Adrian Gropper @.***> wrote:
The delegation issue is more than about a definitions. We need to deal with our intent openly and try to get ahead of the mounting criticism like Phil Sheldrake posted in Project VRM today https://cyber.harvard.edu/lists/arc/projectvrm/2021-09/msg00103.html
Please help me organize a breakout about this for TPAC.
Please consider making delegation a MUST and ignore OAuth altogether.
Also, please consider where and how we can discuss the impact of making Holder a normative concept in our standards. Just because we give someone "consent" by linking control to possession as Holder doesn't mean that consent will not be coercive as with the "shrink wrap licenses" we've grown to despise. w3c-ccg/community#195 https://github.com/w3c-ccg/community/issues/195
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/w3c-ccg/vc-http-api/pull/230#issuecomment-928105906 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAR7T62XRVIQ3FPH5W6CICDUECUPPANCNFSM5D3SPOTA
. 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 .
-- Daniel "Dazza" Greenwood law.MIT.edu http://law.mit.edu/ & CIVICS.com http://civics.com/ Email: @.***
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/vc-http-api/pull/230#issuecomment-928139420, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YK7NUQKNSLSHYJGS43UECXB5ANCNFSM5D3SPOTA . 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.
@agropper
Please consider making delegation a MUST and ignore OAuth altogether.
The bit that's puzzling me about this request is that both GNAP and OAuth 2.0 are "authorization delegation" protocols (emphasis mine). At the moment, the delegation capabilities of GNAP and OAuth2 are essentially identical.
OAuth2 required UMA and ongoing profiling efforts to almost achieve support for self-sovereign (choice) of delegates. GNAP (with RAR) benefits from that experience. GNAP can do what OAuth does but the reverse is not true.
On Mon, Sep 27, 2021 at 4:05 PM Dmitri Zagidulin @.***> wrote:
@agropper https://github.com/agropper
Please consider making delegation a MUST and ignore OAuth altogether.
The bit that's puzzling me about this request is that both GNAP and OAuth 2.0 are "authorization delegation" protocols (emphasis mine). At the moment, the delegation capabilities of GNAP and OAuth2 are essentially identical.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/vc-http-api/pull/230#issuecomment-928227523, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YKZOQLPSZ5ZL23VTHTUEDE7NANCNFSM5D3SPOTA . 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.
A reminder to those that are making their arguments broader and more meta than this PR. This PR is about very specific spec language. Please suggest changes to that very specific language that would remove your objection. At present, we're still debating a single word in this PR -- "SHOULD vs. MAY".
I’m now arguing for MUST.
On Mon, Sep 27, 2021 at 4:21 PM Manu Sporny @.***> wrote:
A reminder to those that are making their arguments broader and more meta than this PR. This PR is about very specific spec language. Please suggest changes to that very specific language that would remove your objection. At present, we're still debating a single word in this PR -- "SHOULD vs. MAY".
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/vc-http-api/pull/230#issuecomment-928240004, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YNARQ4XGRDAYWEFDDDUEDG3DANCNFSM5D3SPOTA . 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.
I’m now arguing for MUST.
@agropper implementer hat on - you will receive a principled objection from me on the fact that there is no current readily available and widely agreed upon mechanism to implement what you are suggesting. Since there may be such a thing in the future, this is why I am not a hard no on including language that permits this who wish to implement even more on the bleeding edge of things such as what is the actual topic of this PR
@agropper - chair hat on - this topic has been dealt with multiple times without a consensus of the group. This indicates to me, as has been discussed in previous meetings on the record that this topic should be revisited at some later date. Your behavior appears to me to be obstructive to the group achieving consensus and moving the spec forward and has the appearance of Sustained disruption of discussion.
The proposed language here allows for a path forward to explore such topics as you are suggesting, and there is currently discussion on topic between "SHOULD" vs "MAY" which have well defined meanings in relation to the topic at hand as noted by @msporny . Please work to move the topic forward in a positive and constructive fashion. I would ask you to consider that this is not an item likely to achieve consensus in the near future. This does not mean that it is not an important topic, only that this particular Work Item does not appear to be a place in which you will get traction on this topic at this time and that you are preventing the work from moving forward rather than helping to move it to a functional state. I would recommend that the mailing list is likely a better topic at this time for discussions such as this, until such time as GNAP et al. further matures.
@mprorock - As invited expert on privacy, I'm doing my best. If the chairs feel I'm not serving my role appropriately, they should institute whatever process to remove me from the VC API group or any other group.
@mprorock - As invited expert on privacy, I'm doing my best. If the chairs feel I'm not serving my role appropriately, they should institute whatever process to remove me from the VC API group or any other group.
@agropper this is a community group with no notion of invited experts. Let's not clutter up the pull request logs. Happy to set up a conversations regarding w3c process, differences between working groups and community groups, etc. If that would be helpful. Just reach out to the Chairs and we can allocate some more time.
I said it before ... but it apparently needs repeating.
PLEASE read the actual definitions of these words (MUST, SHOULD, MAY) as we're using them.
MAYis entirely too loose, as it is too rarely tested (though it often could be, and should register "unsupported" rather than "FAIL").
SHOULDallows you to not do the thing, if you understand the ramifications (which might include interop failure), but pushes hard toward doing the thing.
SHOULDcan and should (cough) be tested like aMUST, though results are a bit more complicated because it might need to register "unsupported" or "unimplemented" rather than "FAIL".
MUSTis totally rigid, and is often inappropriate for immature tech spaces like various aspects of the DID and VC ecosystems.
To elaborate a bit more, since we're still spinning our wheels on this in telecons —
Anyone who has a good argument against MUST in a spec has a good argument for SHOULD (and equally likely has a good justification for not implementing the thing themselves).
The only reason to include a MAY statement is to warn one side of an interaction that the other side MAY do this thing and they'll have to handle it somehow, typically as described in the next sentence or few. If there's nothing special about that handling, the MAY statement will typically be dropped in late edits of the spec.
The only reason to include a MAY statement is to warn one side of an interaction that the other side MAY do this thing and they'll have to handle it somehow, typically as described in the next sentence or few.
I think thats the best way of handling this, given the maturity of the the spec and the lack of viable implementations.
SHOULD allows you to not do the thing, if you understand the ramifications (which might include interop failure), but pushes hard toward doing the thing.
The highlighted part is unacceptable to me.
@OR13 —
SHOULD allows you to not do the thing, if you understand the ramifications (which might include interop failure), but pushes hard toward doing the thing.
The highlighted part is unacceptable to me.
Why?
Also, how unacceptable? Would you raise an objection, formal (in WG) or principled (in CG), to the document if we went with SHOULD here?
As I said in the meeting, there are differences between the Issuer, Holder and Verifier APIs, and whilst delegation might be very important for one of these, it might be irrelevant to another. Therefore a blanket statement about authz and delegation is inappropriate. It would be far better to have separate statements for each of the APIs.
@TallTed this is the CCG, so the only thing I can do is say, in principle, I object to "pushes hard toward doing the thing."... when the language we are using to define the API (which we have agreed to use)... does not allow us to even describe "how to do the thing".
https://swagger.io/specification/
If OAS 3.0 already supported GNAP / RAR... this conversation would have ended ages ago....
I'm in favor of doing ONLY what is possible when following a spec (OAS3.0) which describes how to build APIs that are interoperable.... and that spec has addressed these concerns by describing how to handle them in ways that are interoperable and widely supported today.
If we start breaking what OAS 3.0 can do... we are doing harm to the API and implementers.
A separate work item, dedicated to adding support for GNAP/RAR to OAS3.0 could solve this problem for everyone, not just us... thats where that work should happen.
I am in favor of seeing GNAP/RAR added to OAS 3.0 (in another wg / work item).
I am in favor of defining API security with OAS 3.0. (in this working group, as we have already agreed to do)
I am not in favor of breaking spec conformance with OAS 3.0. (we agreed not to do this, when we agreed to us OAS3.0)
I will object to breaking spec conformance with OAS 3.0, since maintaining conformance ensures implementation is easy and compatible with off the shelf tooling.
@OR13 -- The full language which your latest objection was raised on is --
Implementers SHOULD utilize authorization protocols that support authorization
delegation in order to minimize authorization credential sharing and maximize an
individual's choice in software systems. Examples of these protocols include
Authorization Capabilities [[?ZCAP]] and the Grant Negotiation and Authorization
Protocol [[?GNAP]].
I believe that you have agreed in principle with the guidance that, "Implementers SHOULD utilize authorization protocols that support authorization delegation in order to minimize authorization credential sharing and maximize an individual's choice in software systems," for the quoted reasons (primarily the first).
Therefore, I think your current objection can only be to the examples of ZCAP and GNAP. Is that correct?
Maybe we can get past your objection by changing that second sentence to something like --
Examples of these protocols might include the final versions of Authorization
Capabilities [[?ZCAP]] or the Grant Negotiation and Authorization Protocol
[[?GNAP]]. (These are now in draft status; though they currently appear likely
to, their final versions might not satisfy the described needs.)
@TallTed its close, I am not sure implementers SHOULD have to consider delegation, given OAS3.0 defines OAuth2.0 and OIDC and...
- https://auth0.com/docs/login/adopt-oidc-conformant-authentication/oidc-adoption-delegation#third-party-apis
- https://auth0.com/blog/on-the-nature-of-oauth2-scopes/
TL;DR: Scopes only come into play in delegation scenarios, and always limit what an app can do on behalf of a user: a scope cannot allow an application to do more than what the user can do.
Although stretching scopes beyond that usage is possible, it isn’t trivial or natural – contrary to what common naïve narratives would want you to believe.
In other words... I am not sure THIS spec SHOULD support delegation.
https://spec.openapis.org/oas/v3.0.2
Not a single reference to delegation appears in the OAS3.0 spec.... trying hard to support something that is not mentioned even once in a spec dedicated to describing API interoperability, seems like a bad idea... if defining delegation in APIs is so important, why is it not mentioned once in OAS3.0? (because OAS3.0 defers to OAuth2.0 and OIDC... if it deferred to ZCAPs or GNAP/RAR we wouldn't be having this conversation).
I am fine with MAY support delegation and point to drafts, but really, what is that doing but causing harm... "somebody might try and use these drafts..."... why?
I am not sure folks advocating for "support delegation" understand what doing that in an interoperable standards compliant way means...
If it means we SHOULD use drafts, and I am the last person on this hill I will keep fighting, because it's already a SHOULD... which means it's already not a MUST, and keeping complexity out of the spec is our job.
And before folks point out that LD Proofs and Revocation lists are already drafts... yes, thats my point.... just because you are building on unstable foundation in one place, doesn't mean you should stop caring about foundational stability.... it actually means you should care more.
Perhaps if we accept SHOULD support delegation using community drafts, we can remove LD proofs, status lists, or selective disclosure proof suites? so we don't have so many CCG / IETF drafts as dependencies?
IMO, drafts related to the work of the spec (VC Data Model) are probably more acceptable than drafts related to describing and securing conformant implementations... but maybe not everyone agrees.
Implementers probably need not specifically consider delegation.
We're basically saying their users are going to get an authorization token through unknown magicks, it's worth advising that the authorization to which those tokens apply be as finely grained as possible, and that those fine grains be delegable, such that users with broad authorization do not find a need to share their broad token (or the means to acquire such) but rather can specify that another user can get a token with narrower authorizations.
The point being, to keep the fields of vulnerability as small as possible.
This PR has been converted to a draft since it's clear that we're not going to get to consensus any time soon on it. The group will revisit the PR after it has made more progress on authorization technologies.