Do the /exchanges/* endpoints need authz?
#279
Comments
|
This issue was spawned from a discussion in #48. |
|
Finally, a real opportunity to use Github's new mermaid-js feature!!! :P I'm going to use a "Student ID" as the example to avoid any politically charged reactions from others that might engage in this thread. Here's a rough sketch on how you'd issue a Student ID to a Wallet: sequenceDiagram
participant W as Wallet
participant I as Issuer
autonumber
W->>I: Request Student ID via POST .../exchanges/new-student-id/z123456 (VC-API)
I->>W: DID Auth Request (VC-API + VPR)
W->>I: DID Auth Response (VC-API + VP)
I->>W: Present new Student ID (VC-API + VP)
Now, a careful reader would notice that anyone could intercept .../exchanges/new-student-id/z123456 (this is effectively an Swiss Number capability, that is authz via knowledge), and use it to retrieve a specific Student ID and bind it to a DID that you have control over. So, a naive view would assert that at least two things matter for the security model here:
Attacks against item 1 are software proxies running on the student's wallet. If the student can run software that intercepts and proxies requests (and there is a healthy market for fraudulent IDs in most countries), all forms of software pre-registration and secure communication are defeated. That leaves item 2 as the only real mitigation, and even that needs to be done on a regular basis (or at least, before a critical use of the ID). Even if a proxy is not being used, the device can be sold and/or re-purposed (new biometric authn registered/changed). Does the above resonate? Is there a different security model under consideration? |
Yes it certainly helps to get to the next level of detail.
Im not sure this is quite the right framing of the options, the questions I have and apologies for just dropping a list of them I'll attempt to explain my perspective below:
In my opinion, what happens before this flow is that the wallet has to obtain this url (capability) some how. To me that is an authorisation flow. One where the wallet makes a request to get a particular credential, for a particular user (e.g this URL). Obtaining this authorisation usually involves authentication and consent from the user (often the subject of the credential in personal identity usecases). Who this entity the wallet goes to, to obtain this url (capability) also affects these things, im assuming logically the entity that you obtain this URL from is the same entity the wallet is interacting with in the above sequence diagram? Because the fact that the capability is in the form of a URL like this implies that there is some state being managed behind the scenes here in relating the id featured in the URL to some ongoing transaction or session? |
|
IMO the last paragraph above touches on some of the limitations involved in using URL based capabilities rather than say cryptographically secured tokens, the former imposes more session based state management by the issuer and likely a coupling of the entity responsible for generating the capability to the entity where the capability is exercised (e.g the "issuer" in the above diagram). |
I'll try short/quick answers to these and then follow them up with a more detailed diagram that attempts to summarize the answers.
Summarized in the diagram below.
The simplest case is that the Issuer generated the URL. A more complex case is that an entity that the Issuer can communicate with, in a SECURE and out of band fashion, generated the URL. Yet another more complex use cases is that a completely different entity generated the URL and placed encrypted data in the URL (e.g., CWT) that only a particular recipient can decrypt. For the purposes of simplicity, let's just focus on the first two, because we haven't found any use cases that need that last one.
If by "user" you mean "the subject of the VC", then yes, it did. When the the subject of the VC is through the auth process, they're given the URL over a secure transport (e.g., same device CHAPI). Yes, insecure transports (cross-device QR Code) /could/ be an issue -- and we'll get to that later.
The presumption is the URL is valid until they pickup their VC OR a certain amount of time has elapsed (15 minutes). So, yes, replay attack prevention is expected to be implemented at the Issuer for "high value" credentials.
The presumption is that they're in the same trust boundary in the simplest case. There are cases where one can "hop" trust boundaries via the "interact" field in VPR. So you can start at one trust boundary, do part of the flow, and then hop to another trust boundary (using VPR + any other protocol). When you do this you MUST ensure that there is some sort of transferrable trust from one boundary to the other -- like a JWT in a URL or VC in POST data -- both of which can be expressed via VPR "interact".
This is an open question. I think your assertion is that consent MUST be acquired before they initiate the VC exchange. In that case, there are multiple ways it can happen, but the most straightforward is: The Issuer can ask the subject "Do you want to store this Student ID in your digital wallet?" -- and then a mediator is invoked or QR Code is displayed.
Yes, this would be the first exchange, where the Issuer would state the features it needs from the wallet (query 1 in the VPR), and the DID Auth request (query 2 in the VPR), and the wallet would receive those and, if it can't fulfill either query, tell the user why. While failing isn't the ideal outcome, if the wallet can't fulfill the request, it can't fulfill the request. There is an option here where the wallet can register features it has in the mediator (CHAPI)... but remember, different profiles in the wallet might have different capabilities. So, even if a wallet supports CryptoSuiteX, that doesn't mean that any of the active profiles (DIDs) in the wallet does. This is why we do not believe that having a static wallet configuration can solve this, fundamentally dynamic, problem of configuration. It has to be done dynamically, in the protocol. I'm out of time for tonight, but hope to draw up the full flow diagram, as you requested, detailing the above, 12-ish hours from now. |
Ok understood so the most basic cases are when the identifier encoded into the URL is just a random identifier that is associated to some session state on the issuer?
Yes i do, that clarifies it.
Ok.
Ok details are still fuzzy to me, but I think I understand the intent.
Doesn't have to be in all cases but I think a protocol that doesn't allow this as a possibility will run into issues with certain credential types.
To me this is too late, by then the end user has likely been through an auth journey, probably clicked yes to a bunch of T's & C's, maybe filled in some data and then to find out after all that their wallet cannot support the credential is liable to just annoy users immensely. I think the negotiation of capabilities has to happen much earlier.
I agree the information is liable to change overtime so the model needs to account for that, but assuming that it is so dynamic that the most practical method is to send all information on every issuance flow is extreme. |
There are a few things to consider here.
|
I follow this point, but im struggling to see the conclusion you are drawing here, when is it ever advantageous to delay failure in a system intentionally, knowing full well that the engaging party (the End-User) is having to invest in the process. To me I dont see how this doesn't always end in End-User frustration or them making a decision from a position of compromise (e.g fine i'll store it in the Issuers recommended wallet because I've been through all of this work to get this far).
Understand the theory here, but again without seeing how it shakes out end 2 end its hard to fully evaluate
Again I think I understand your perspective, but unsure how you are reaching your conclusion. |
|
I'm providing ONE example of an end-to-end flow that is end-to-end secure -- there are other end-to-end flows that we can get into later. This does not focus on client feature detection, that's issue #280.This is a same-device flow using a web-based wallet: sequenceDiagram
participant H as Holder
participant WS as Wallet Service
participant WA as Wallet App (Website)
participant CH as CHAPI
participant IW as Issuer App (Website)
participant IS as Issuer Service
autonumber
H->>IW: Authenticate to pick up Student ID (authn via MFA - (OIDC | email + password) + pin)
IW->>IS: Generate VPR (bind to MFA outcome)
IS->>IW: VPR (containing .../exchanges/new-student-id/z123456)
IW->>CH: Invoke CHAPI with VPR
CH->>WA: Invoke registered Credential Handler
WA->>WS: Instruct Wallet Service to perform VPR flow
note right of IW: Calls below this note are proxied through the Issuer Website to the Issuer Service
WS->>IS: Request Student ID via POST .../exchanges/new-student-id/z123456 (VC-API)
IS->>WS: DID Auth Request (VC-API + VPR)
WS->>IS: DID Auth Response (VC-API + VP)
IS->>WS: Present new Student ID (VC-API + VP)
Here is the same flow that is just as secure using Native CHAPI (Web Share): sequenceDiagram
participant H as Holder
participant WS as Wallet Service (in Native App)
participant WA as Wallet App (Native)
participant CH as CHAPI
participant IW as Issuer App (Website)
participant IS as Issuer Service
autonumber
H->>IW: Authenticate to pick up Student ID (authn via MFA - (OIDC | email + password) + pin)
IW->>IS: Generate VPR (bind to MFA outcome)
IS->>IW: VPR (containing .../exchanges/new-student-id/z123456)
IW->>CH: Invoke CHAPI with VPR
CH->>WA: Invoke registered Credential Handler
WA->>WS: Instruct Wallet Service to perform VPR flow
note right of IW: Calls below this note are proxied through the Issuer Website to the Issuer Service
WS->>IS: Request Student ID via POST .../exchanges/new-student-id/z123456 (VC-API)
IS->>WS: DID Auth Request (VC-API + VPR)
WS->>IS: DID Auth Response (VC-API + VP)
IS->>WS: Present new Student ID (VC-API + VP)
Do you see anything here that is not end-to-end secure, @tplooker? |
msporny
assigned mavarley, msporny, dlongley, peacekeeper and tplooker and unassigned msporny, mavarley and tplooker
What I'm trying to highlight as important is not the difference between non-optimal failure mode UX and a perfect solution (no drawbacks) that addresses it. Obviously the latter is preferable. Rather, the trouble is with the difference between non-optimal failure mode UX and a solution to it that harms user choice more in ways that may be indirect and, therefore, can be overlooked when viewing the failure mode UX in a vacuum. This is, to me, a significant concern with a solution that requires user wallet or wallet vendor registration with the RP. If it's more indirectly harmful to users, I am suggesting that accepting non-optimal failure mode UX is the better choice (absent any other options). In other words, we should optimize for user choice across the ecosystem generally, not just in failure mode UX. |
|
I have always felt authorization was out of scope for this API, given that it is meant to be completely generic. Consider the following scenarios:
(1) does not require "authorization". It's a digital Big Ben. Since the API is generic, and we don't know what we are protecting, authorization should be out of scope. Removing the requirement for a specific authorization protocol opens up the scenarios in how this API can be used - BUT it also may lead to interop challenges (how does a client know how and when to call an API endpoint?) and also may be a "foot gun" if we cannot provide proper guidance/best practices on how to use this new tech in a secure manner. By comparison, the FAPI API was able to carefully define and specify the authorization requirements because it also defined the contents of the API (various levels of financial data, from ABM locator to account transaction history). Without a concrete API context here, we will continue to spin on authorization requirements, I feel. |
Thanks this helps
I think being absolute in feedback for this is quite difficult because it depends on your assumptions. Do I think there are certain use-cases that work with this model? Yes. However I do think there are some significant limitations which would make this approach difficult to address other usecases.
I agree with much of Mikes comments above, however I think the problem I'm seeing is that this API appears to be re-inventing certain aspects of delegated authorization protocols, namely the expression of the authorization capability (URL) and how it is transmitted to the authorized party (CHAPI), rather than looking to use a standard protocol to do this instead (OAuth2). In doing this, the work required for this API's definition gets exponentially more complex. The benefit of using standard authorization protocols is that you get a consistent approach that has a wealth of possible mechanisms you can layer in to satisfy different security models. For instance if bearer based access tokens aren't secure enough, layer in DPOP. Want to mitigate CSRF, add in PKCE. I dont see the same depth in the possible choices here because of how the flow is modelled and that is likely where the limitations will arise. |
Right, understand and agree with the position, I just think we may disagree on whether or not there are alternative protocol designs that resolve this UX issue but still preserve user choice.
Again, I think the disconnect here is that I see no difference in a protocol that does "wallet registration" and one where the "wallet is negotiating its capabilities with the issuer via a DID Auth response", they are one in the same in their purpose, mechanically they may do it slightly differently but any risk that manifests around user choice is the same. |
|
@mavarley you didn't answer the question :) -- Do you see anything here, in that ONE specific flow, that is not end-to-end secure? I get all the other points you're raising, and we'll get to them, but we need to start somewhere. Let me try going at it from the other direction: The same-device end-to-end flow described above is secure for both web-based and native wallets. It does not need OIDC, DPOP, or PKCE to be secure. Full stop. I believe @tplooker has confirmed that it is end-to-end secure in his response, and would like to discuss other use cases. We can talk about cross-device flows and security models for those after we get confirmation from everyone that the end-to-end flow described above is secure. :) |
|
I'd like to see if we can work through some of the concerns you raised to whittle down the list:
If CHAPI is trusted to prevent MiTM attacks (in the same way TLS is with OIDC), then this attack should not be possible. That's the limit of the security model and it functions the same way with OIDC. Can we agree to this or is there some other concern?
I think the issuer asking "Do you want to view this website using browser X?" before showing their web page would be very limiting in a negative way. I consider the question above to be of the same sort with similarly negative consequences. I consider this to be an information minimization use case -- where the issuer doesn't need to know which wallet I prefer to use and that knowing that information could be used against me, harming my free choices. I think the roles are being confused here. The issuer is not my agent. The browser is and my wallet of choice is. The browser (or a polyfill for it like CHAPI) should help me make sure I choose the right wallet to use. And my wallet of choice, as my agent, should help me make decisions related to credentials (like whether or not I store them from certain issuers and whether or not I share them with certain verifiers). This is the right model, IMO. |
Actually, I answered the original question - the title of this issue and the original one in the first message:
Without understanding what is being protected, or the risks, no evaluation can be made as to the "Security". But I did dodge the latter, more specific question on the proposed flow:
So here goes. If we apply the following assumptions:
I believe the above is secure enough to transfer a credential relating to an account holder to a wallet of the account holder's choosing - the exchange ID is acting as an auth token, effectively, until DIDAuth can be completed. The risk on the binding of the credential to the same subject in the web session is, as @tplooker pointed out; the 'wrong wallet' may get selected on a shared machine, the wallet or DID method may not match the required criteria, there is no confirmation on the web channel as to which holder software the credential was actually delivered to, etc... but depending on the credential's usefulness/value and associated protections, maybe these are not concerns. And as I noted above, if there is an additional binding that can be performed (like the first message has a PKCE like value that was bound to the original session - or there is an SMS one-time-code that can be entered from the holder software...) then these may bolster the security posture, but these types of nuances depend on the resource being protected. No one can answer "how much is secure enough" without the full picture - but again, this spec/API is being designed generically - and should leave room for a wide range of use cases and security contexts. I will note I would have serious reservations about requiring CHAPI being tightly coupled to this API, for the exact same reason. |
|
To be clearer, no I dont think this model is sufficiently end to end secure for several important usecases. I also dont see how you can layer on additional mechanisms to secure it further, because of how the flow is structured. I think the assumption that you generate the capability before knowing anything about the party you are giving it to, is wrong.
As said above I dont believe this is the case for several important usecases.
Its not just CHAPI that needs to be secure against this here to a comparable level with TLS, its everything from the server that generated this URL through to where it ends up. Its also not the only layer of security OIDC or OAuth2 has when interacting with the token endpoint either, you could use client authentication with public private keys or PKCE to further mitigate several attack vectors. You cant do this with the above flow, because there is no interaction with the wallet prior to just handing them the capability (URL). I also dont think you can equate the security provided by a transport layer to a javascript polyfil providing mediation that requires end user interaction, they have completely different characteristics.
Sure but thats because your mental model is that a wallet is akin to a web browser, when mine is not.
I get the issuer is not my agent, but do I not interact with the issuer via an agent, the Browser? And then why is it not a good idea to support a flow that allows via this agent for the issuer to convey to me the implications of issuing a credential to my wallet and obtain my consent? Piping this through the wallet is just vastly more complex and has significant implications around the trust model. |
Sure, I get the existing definition of CSRF perhaps does not fully apply here, but I dont think this means the attack vector doesn't exist even if it does not fit neatly into an existing definition.
Sure but none of this is afforded when talking to native apps from CHAPI right (via web share)? So this only works for web wallets?
As a counter though, the fact that a protocol which has been widely used for over a decade was able to easily extend to mitigate this threat vector IMO is a testament to the protocol. We should be careful not to wield the sword of hindsight against protocols like OAuth2, for example saying it didn't predict the need for this particular mechanism as a form of critism I think is miss placed, the reality is the protocol easily adapted with the addition of a simple extension. Also it is this very flexibility within OAuth2 OIDC that I dont see with the CHAPI + VC API that has me concerned.
Yes to be totally clear I am making this argument although I dont think it "kinda looks like we could use it" im convinced, as are many others that we can, it doesn't mean we dont have to reinvent anything, but invent less, yes definitely.
Yes to be clear here it is between the wallets request for the credential (onbehalf of the end user) and the end-users authentication (and potentially consent) with the issuer to issue the credential.
Yes this is because your mental model starts with the End User visiting a website, authenticating, invoking CHAPI and then issuing the credential, what I'm saying is I dont think that is right ordering of events in many usecases. In many cases it should be visiting a website, invoking CHAPI, authenticating the user (or just checking they already are on the device you are accessing the wallet from) then issuing a credential.
Personally I think the assurances that fancy maths (cryptography) can supply alone in the application of digital identity technologies is overplayed, people appear to approximate the usage of cryptography in cryptocurrencies and conclude that it alone can serve a similar basis for identity technologies. The latter in many ways is far more complex and involves way more social constructs that makes it incredibly difficult to just say "trust the math". We need to be clearer on what the purpose of the cryptographic binding established when a credential is issued actually even represents, to me in many circumstances its an authentication factor at best but alone proves next to nothing about whether the End-User (true credential subject) is involved in a credentials presentation. If a person has two sets of cryptographic keys one tied to their holdings in bitcoin and another tied to their drivers license,
There is a lot of really good feedback in here that I want to be able to respond to however Im not sure a GH issue is the best way to do it, I could try capture it in a google doc? Otherwise happy to just respond inline to the GH issue. |
This is a really important point that I think is being overlooked, what happens when you execute a redirect into an OIDC flow is completely up to the issuer and you have the full power of the web to build whatever user journey you want including authenticating the user, so I also dont really follow the argument that OIDC is overly limiting in this respect nor do I see a blurring of responsibilities. To be clear OIDC discovery is optional in the flow I shared above, the wallet doesn't have to do this nor do the credentials offered by a provider need to even be published in the metadata, the important thing is that the user gets authenticated and the wallet gets authorized to obtain the credentials its after. |
|
To offer more context, if you want to accomplish a flow where you want to trust the channel in which you are passing something to the wallet and skip user auth on the device you are provisioning the credential on, then we are working on this variation in OIDC CP /OIDC4VCI known as pre authorized code flow, however there are a few features I think that make it quite different to the one shared above.
|
|
I was thinking about a flow where a CHAPI initiated flow could help ensure a "tighter subject binding" through a flow, and support an early fail/bailout in case the person does not have a compatible wallet...
In red there are internal calls between the Issuer and VC API service that are out of scope (I think). Not sure how to structure the VPR messaging to support the callback/webhook (and maybe another CHAPI flow is required) but the point is (that I am trying to get at) is by breaking up the CHAPI flow above, there is a way to achieve a 'workflow' like experience that also helps bump up the level of assurance. I am not suggesting all CHAPI flows need to change to the above; merely exploring possibilities. PS: I will note that in step 2 in the diagram in #279 (comment) this call is likely authenticated/authorized and results in the exchange-id as a bearer token, which is also acting as the authorization to execute the exchange API -- seems like we danced around a lot, but the VC API still requires authorization ? |
That's not the complexity I was referring to. What flows you implement inside of a particular protocol and how complex those are / can be, is a question for a layer above the protocol itself. Ideally, a protocol keeps responsibilities separated by role, offers good composition via simple primitives, and gives people as much freedom as possible for their flows at that layer. What I was talking about above was what every user of the protocol itself needs to do regardless of their particular flow, e.g., how many components must they implement (or use libraries for), which extra options do they need to consider (PKCE? DPOP?), etc. to ensure the security model works and so forth. To this point, one complexity I mentioned that isn't needed in the CHAPI + VC-API security model is software client registration and authentication. |
If we take the purpose of registration in OIDC to be the ability for the wallet to express what it supports so that it obtains a VC it can actually use, then I dont believe this isn't needed in the CHAPI + VC-API, it may mechanically be achieved in some other manner but its a stretch to say that the way it chooses to achieve this is an overall reduction in implementation complexity. Similarly Im not sure what is being defined here as client authentication so its difficult to know what you are talking about and hence whether it represents implementation complexity that CHAPI + VC API some how escapes. |
I've been trying to make it really clear that it's important to separate that out. It's not needed for the security model in CHAPI + VC-API but it is in OIDC. If we want to talk about UX, etc. -- that's fine, but it's a separate subject. How we solve particular problems there may have a number of different possible solutions, each with advantages and disadvantages. If we come up with a more elegant solution to a UX issue than "client registration", OIDC still needs registration for its security model; that's important to note. It is true that if we find that some element that is needed for some protocol's security model has good trade offs when reused to solve a UX problem as well -- that's great, but we need to be more rigorous in saying what things are for, why they are necessary, what the trade offs are, etc.
It absolutely is a reduction in complexity (and attack surface). The effects of security bugs are not the same as compatibility bugs, just as another simple example. |
It doesn't require "client authorization" (read: wallet authorization). There's an expectation that any backend service that the issuer uses would either have authorization of some sort or be behind a firewall, etc. -- but none of this is relevant regarding whether a user's wallet of choice now needs to be authenticated and/or strongly identified to the issuer. That's a total different requirement. |
Yup, +1 to your example of a "tighter subject binding" that shows one way that the primitives provided via CHAPI + VC-API can be composed to achieve a particular use case. |
This is a different kind of attack that assumes the security model is broken. The CHAPI + VC-API security model assumes CHAPI is secure. It's similar to assuming that wallet, RP, and issuer software are secure in any other case (like OIDC). If you don't have client authentication in the OIDC case, even if those other things are secure, there's an attack. If you don't have client authentication in the CHAPI + VC-API case, there's no attack. That's what my statement meant. If we want to talk about "how to improve the security of the CHAPI mediator itself", I think that's an interesting topic of discussion, but it's a different discussion. Again, I think we need to be more robust with the layers at which we're making comparisons here. That being said -- on the topic of "improving the security of the CHAPI mediator itself" -- the above attack you mentioned could be mitigated in an interesting way:
Note that this still can all be done without any "client authentication / identification / registration". |
No, the OIDC flows we've seen require the issuance process to start via an unbounded public VC selection list published by the issuer that is downloaded by the wallet and rendered in a "wallet marketplace". The issuer must use this primitive to issue their VCs. I detailed a number of problems with this approach in my post. The biggest one is that the issuer loses their ability to manage the user relationship, experience, and eligibility checks at the start of their issuance process. We could end up with issuers giving their users instructions like this: "Ok, once you choose your wallet, make sure that you scroll down to pick 'Greenwood Commons VC' in your wallet marketplace, not 'Common Greenwood VC', otherwise you'll have to do this again. Also, make sure that you have VC X, Y, and Z if you're going to pick 'Greenwood Commons VC', otherwise you'll have to go back and pick 'Albatross Greenwood Commons VC'." This is why I suggested that having the user choose "flows" at the wallet marketplace may be better. But even then -- maybe issuers will just show one choice -- because they want full control over the process -- and it becomes a wasted part of the UX. Hopefully this makes better sense now. |
Like I said in my other comments, there are not just wallet eligibility concerns, but also user eligibility concerns. I tend to think that user eligibility should be prioritized over wallet eligibility. Reasons:
|
To be clear OIDC Discovery is never required its just a method to support this style of issuance when desired the credential offer sent to the wallet could equally be (note this is just an example)
The wallet can then if it desires just skip ahead straight into an OIDC request with the |
But which flow? In the diagrams we've been given, there's no way to whittle the choice down, but, as mentioned, an unbounded list of VCs is shown in a "wallet marketplace UI". I do tend to agree that issuers will end up abusing this primitive such that there's only one choice -- or very few choices -- because they will want to be in charge of this selection and where the flow heads on their own site.
Yes, the user will have invested very little. But if they make a choice and move forward -- and that choice isn't "the right one", they will be very annoyed. Again, this implies that issuers, in order to avoid this, will abuse the "public VC selection list" primitive not to show actual possible VCs the user could get, but instead would make each item in the "VC list" be a representation of "all flows that require wallet features X" instead. This may be awkward for users -- have we considered what it would be like? It seems the flow in the diagram may be optimized for demo sites or small / one-off issuers. What I'm saying is that the primitives feel off here and it's a result of taking away responsibilities from the issuer. Is that making sense?
To further analyze whether the primitives and their semantics are right here ... what use was the "public VC selection list" in this flow? What does having it accomplish?
How does the wallet know when the exchange has ended? Does it assume it's over based on receipt of a VC? Is that what is meant by "presumably all the interaction has already occurred"? What if there are more VCs for pickup and more to do in the exchange -- how does the wallet know how to direct the user next? There seems to be a missing primitive that clearly marks the end of the exchange; instead, it seems to be presumed. I'm worried about composability here. |
Then I would recommend eliminating the "wallet marketplace" option entirely, instead requiring an approach that mitigates the concerns I've raised. Side note: I think I've also lost the thread here on how the user makes a compatible wallet selection or where / how the required wallet features are expressed. I'll see if I can find it in the issue here if it's already been said -- otherwise, could you elaborate on that part? |
Im not sure why eliminating it is required, if its optional and services other usecases why would we remove it? what does it prevent you from doing that you want to be able to do? I also dont really it as a "wallet marketplace" its just a way for a provider to advertise what credentials it supports issuing |
We should eliminate it as a part of a core protocol because of ecosystem complexity. We should be trying to optimize for the minimum number of primitives that achieve the maximum number of use cases. Then we should pick primitives that can be layered/composed to maximize the next band of use cases. I've noticed a pattern in the discussion (that we're all guilty of), of just referring to technology X to solve problem Y... and we're picking and choosing each technology and saying they are "optional". Ok, fine... but what's the baseline that everyone is expected to implement and how many use cases can we achieve at that baseline? IOW, it's always possible to tack on optional technologies... OIDC4VCI + OIDC Discovery + SIOPv2 + DPOP + PCKE ... or VPR + VC-API + did:web keyAgreementEncryption + ... and when we do that, we tend to just go around and around in circles because... if you can solve a problem using one technology, it's probably true that you can solve the same problem using a different technology plus adding a bunch of add ons. Person A: CHAPI enables user-driven mediation. and around in circles we go. How can we structure this conversation so that we start converging? Would it be helpful if we state things that need to be a part of the core interoperability profile? Can we start with "Mediation is a mandatory part of the core protocol?" -- I only offer that because it seemed like @tplooker agreed to that on the CCG mailing list... and I don't know where @mavarley is on that right now. I'm asking because I'm at a loss right now. |
Just a +1 to this comment.
(big apology in advance and asking quietly...) what do you mean by Mediation? I only ask because SK uses the term internally in several different ways... As per #181 there may be scenarios where Mediation is not required? |
I think the disconnect here is that OpenID CP / OIDC4VCI doesn't always assume that you start from a channel, like a browser that requires mediation. Instead you could be scanning a static QR code from a piece of paper that contains |
Yes, that was covered here: https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0010.html Excerpt below: On 4/3/22 2:06 PM, Brian Richter wrote:
Yes, we need to find a better term... even "wallet mediator" isn't descriptive enough. A "mediator", as used in CHAPI, is a piece of software that enables a Holder to choose which "digital wallet" they want to use for a particular transaction. This is in stark contrast to how social login works today, where you are typically only given 3-4 fixed/centralized choices: Login with Google/Apple/Microsoft/Facebook A mediator typically supports registration, selection, and deregistration. It also has other properties, like preventing an Issuer or a Verifier from discovering what Wallet the Holder is using (one strategy for preserving a competitive ecosystem). A mediator is what enables digital wallet choice in the SSI ecosystem when you want to invoke a digital wallet, regardless of whether it is a web app or a native app, on the same device (such as your laptop). A mediator is agnostic to the messages flowing over the communication channel. At present, CHAPI is used in the Verifiable Credentials ecosystem to select a wallet provider. It could also be used to select from among your OIDC providers.
The meaning in CHAPI is slightly different. CHAPI is used to route messages to agents without a consideration to whether or not they're offline (e.g., CHAPI can work in both offline and online scenarios since it's purely client-side technology that lives in the browser). |
|
@tplooker wrote:
Yes, true (though that point was never lost on me)... and this is one of the problems w/ the current conversation. In fact, I call out exactly the statement above in this comment. You are "whatabout"ing cross-device QR Codes (which DO need some sort of protection) when we haven't established whether you believe "wallet mediation" is required in same-device digital wallet invocations. That is, you're talking about a cross-device use case without us all getting on the same page about the same-device use case. I feel like we're close to getting on the same page about same-device use cases... can we run that to ground first? We might try to start focusing on one class of use cases (e.g., same device wallet invocation) and come to some conclusion on the simplest/minimum primitives needed for that use case, and then moving on to another one. I do admit that we need to think about all of this holistically... however, that is leading to us talking in circles (sort of, I also admit that we're making progress with every circle -- this process was bound to be messy). Can we run the "Is mediation required for same device wallet invocation use cases?" to ground? If we answer that question, we might be able to answer the question raised in this issue. To be clear saying "Yes, wallet mediation is required for same device wallet invocation use cases." does not require one to pick "CHAPI/OIDC/VC-API/VPR/etc." -- it's just an acknowledgement that we value addressing that use case. Digital Bazaar values that use case because we have customers that require the ability to invoke both native wallets and web wallets in same-device flows. |
|
I dont think whether we are using a mediation component like CHAPI as a way to establish a communication channel between the wallet and issuer should be core to the protocol design here, instead it is an important layer above the protocol. If we make it one, we risk designing a protocol that only works over CHAPI and I disagree with that intent. Where components like CHAPI become important in this particular conversation is the trust and assurances it provides as a channel to allow an issuer to communicate with a wallet. I believe it is better to start this protocol design from the perspective of an untrusted channel between the issuer and wallet, rather than trusted (e.g CHAPI). Because designing a protocol based on the former will mostly likely mean the flow will also work over a trusted channel like CHAPI, its just perhaps not as optimised. Whereas if you start from a world view that the channel must be trusted, chances are the assumptions in the underlying protocol will be invalid for the cases where it is not, hence causing a revisit of the core protocols design. To answer your question directly Manu, I do see huge value in same device based flows through a mediation layer, however I think starting with these as the core requirements, risks designing a protocol that only works in that case. |
|
Bringing in a conversation from another thread where we had talked about protocol intents and layering: We have:
Examples: Not all of the above are necessarily required for all interactions. |
|
Can we update the title? I'm not sure we are still talking about /exchanges/* endpoints. If we are, can we can an enumeration of those endpoints, including the components on which those endpoints are expected? |
|
The group discussed this item on 2023-01-17. It was noted that many months have passed since this topic was discussed and in the meantime flows have been added to the OIDC4 flows that do not require registration or allow dynamic client registration. @dlongley noted that we should have authz for the creation of exchanges endpoints but should not require authz for the usage of the endpoint you create. @dmitrizagidulin agreed with a +1, authorization for using the exchanges endpoint should be optional because there are several valid use cases where authorization is done inband as a part of the exchange... DCC learner credential wallet uses such a flow... this is different from having authz on the API endpoint itself. Alan Karp noted that for administration, you will probably have authz. For public endpoints you almost never want to have authz, unless you want protection against DoS, in which case you went to other endpoint first, get an authz credential, and then provide that to "public endpoint". You absolutely don't want authz REQUIRED for a public endpoint. @jandrieu noted that he was still confused about what exchanges is doing, so difficult to comment on technical ramifications, but noted that those implementing it find it useful. Why isn't it just a token passing when you have an endpoint that you hit and you get a "you need to get something else" -- who is telling whom that a flow is going to happen... and then "you need these things for this flow". @TallTed noted that he was confused as well -- designing things to not require authz has a high potential for security issues down the line -- in most deployments, this might not be necessary (especially in test), perhaps some kind of tokenization needs to be involved. When you come to newly created endpoint, you have to have token from person that requested endpoint. @dmitrizagidulin explained what /exchanges/ endpoint was... there is a need for iterative credential issuance/reissuance -- so endpoint belongs in issuer endpoint, but closer to issuer rather than verifier -- idea is it's a multistep way to provide credentials, where issuer can, in stages... "before I can issue to you, I need X, Y, and Z -- and might include authz" -- reason to do authz on application level is to allow discovery, to allow exchanges endpoint to specify which VCs/authz it needs to issue/reissue a VC. @dlongley noted that this isn't necessarily on issuer coordinator component... end user is using issuer coordinator website, via that interface, they make a decision to request a VC, upon that request, issuer coordinator creates exchanges URL that follows process that wallet needs to go through, hands that exchanges endpoint to wallet, which then (gets into authz discussion), URL could be seen as an authz capability (unguessable URL and only someone who's been handed the URL can go to the endpoint and proceed). When they hadn that off to a digital wallet and visit the URL, that URL might ask them for additional VCs... endpoint could be implemented on issuer coordinator to allow custom code, or could be implemented through external exchanges service that operates on basic primitives -- some flows can be easily constructed form a set of VPRs and VC templates, other flows cannot. It depends on the type of flow the user is going to end up going through. That's how exchanges set of APIs should be understood. @PatStLouis noted that exchanges service makes more sense now, in case of Aries, typical flow is credential offer, then credential request, then issuance. Issuer offers VCs, Holder requests it, Issuer issues it. How that language is used here "issue" -- signs the VC, adds the proof, previous to that "issuing" had the whole flow "to sign a VC and send it to wallet". Exchange service in VC API is whole communication between holder and issuer so they can understand how to exchange information, hopefully at end of implementation, Holder has VC in the wallet. Regarding authz, there is the concept of discovery, wouldn't discovery be treated separately? Unauthenticated endpoint that says "Here are the 'languages' that I can speak, which of these interactions would you like to begin? There are the functions I support, is that the type of discovery endpoint that the issuer can provide?". @jandrieu Why not just as a response when you try to get a credential issued and you hit the issuer, why not use a redirect pattern, which is a more common pattern on the web? @dlongley noted that redirects don't work, you might not want to lose state, you might need to go to different device, different app, that pattern doesn't cover everything that needs to happen. @jandrieu didn't mean literal HTTP redirect, he meant the use of the @PatStLouis noted that something doesn't sound secure about this. @msporny noted that this works just like a regular website, which doesn't have authz on the first hit. @dmitrizagidulin noted that these are exchanges under opaque strings, this is a specific opaque exchange that usually the wallet arrives at out of band. @TallTed if this is equivalent to homepage optional activation seems ok, but making it optional endpoint, they might not implement this authz piece they might change implementation because they discover they need that -- make the @msporny asked if anyone had concerns about "A given exchanges endpoint should be a URL capability or establish authz through exchange flow itself." Alan Karp noted not an objection since we're talking about "private endpoints". @msporny noted it's not necessarily private, you have to interact elsewhere. @dlongley noted that there are multiple options here where you could get the capability URL. Alan Karp noted that you don't need authz to hit it the first time. When it's part of a flow, you get capability to invoke. |
|
We discussed this on the 2023-01-24 telecon. @jandrieu noted that there are at least two things of concern 1) difference between endpoints, between issuer coordinator and verifier coordinator and verifier service (secured thorugh some mechanism) vs. verifier coordinator needs auth or not. 2) Establishing authz through exchange flow is still having authz on that exchange flow. @dlongley thinks what Alan was saying fits into quote above... "A given exchanges endpoint should be a URL capability or establish authz through exchange flow itself." -- either there is a case where you are using a URL capability (it's not advertised and sufficiently randomized to not guess URL), or case that there is a "public" URL, anyone can hit that, when you hit that URL, you get a VPR that you must respond to and in so doing, some sort of authz is going to be established through the exchange flow. @dlongley feels like quote covers both cases. Either it's a URL capability (authz by holding the capability) or authz is established upon interaction. @msporny asked about "first come - first served" use cases? @dlongley noted that even in those cases, authz of some kind will be done to prevent DoS, or limited number of credentials to be given out, one over limit - rejected, implies some sort of control over using endpoint. @jandrieu noted "proof that service is running" doesn't fit into that use case. @dlongley noted that even in that use case, it'll probably be rate limited. @msporny noted that if we enumerate all the possiblities, if we answer the question? @dlongley and @jandrieu noted that if we go endpoint-by-endpoint, we answer this question. The next step for this issue is to close the issue once we assign what types of security are on an endpoint. |
|
The group discussed this on the 2023-04-11 telecon: The group has set available security schemes for all endpoints in PR #334, which addresses part of this issue. The next step is to raise a PR to refactor exchanges as a first-class component and explain how exchangers are created/configured and then how exchanges are built off of exchangers. |
|
Waiting for #353 to land and then will build off of whatever text is added to the spec as a result. |
and others
At present, the
/exchanges/*endpoints are being implemented to have optional authz. That is, implementers can add authz to those endpoints if their use cases require it.At least one implementer does not require authz for performing presentation exchanges, but rather does authn/authz in the
/exchanges/*protocol itself. One use case has the Issuer implementing the/exchanges/*endpoint, a Holder engaging with the endpoint, and the Issuer responding with a DIDAuth request to authn the Holder. This does not utilize OAuth2 to establish software client authz.This approach has been challenged to be insecure, so this issue is to discuss the attack models and security characteristics of this approach.
The text was updated successfully, but these errors were encountered: