1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Enable a device to direct requests from web sites to appropriate app for processing

Issue #2121 resolved
Tom Jones created an issue

For a verifier to get a credential from a holder that may have multiple wallets, there needs to be a capability for the verifier to express their need for credentials in a manner that is agnostic to the specific format of the credential that the user has loaded into their device. This is a proposal to create a spec for the request or query to be sent to the device (or browser). The means by which the device directs the query to the appropriate app needs to be handled by other organizations. A draft is currently being circulated.

Comments (13)

  2. gffletch

    I would like to add that I think making Verifiers understand all possible credentials that may contain the claims they are interested in is a lot of work to put on the Verifiers and leaves a lot of ambiguity for the Verifiers in how they construct a request.

    At the Verifier, they know what claims they need from the user. For example, let’s say “age over 13”. That claim might be in 10, 20, 40 credentials? Does the Verifier need to list all possible credentials in an Or way just to get the “over 13” claim?

  5. Joseph Heenan

    Again, this issue does not appear to be in scope for the connect issue tracker. Can one of the chairs please either explain why it is in scope or close it?

  6. Michael Jones

    I agree that this largely duplicates the OpenID4VP issues cited by Joseph. Tom, if you want to add comments to those issues, that would be useful.

    I propose to close this issue for the reasons cited by Joseph on the next working group call, unless a reason is cited to keep it open.

  7. Tom Jones reporter

    i am on the dcp call now and see no evidence that there is any consideration for either users or verifiers concerns in that group. They don’t even support the provisioning of delegate credentials. In any case i would like a discussion by the group. I guess what i was trying to get to was a wallet query language where credentials, at least on VCs, were not the only type of object returned. Specific examples are SHC: and payments. Perhaps OpenID is not the right place for such a query language?

  8. Joseph Heenan

    I spoke to Tom after the DCP call; I think we agreed there’s overlap between the issue here and https://github.com/openid/OpenID4VP/issues/112 so I suggest we continue the discussion in the DCP working group on that OpenID4VP issue.

    re: provisioning delegated credentials, I believe that is supported by the current OpenID for Verifiable Credential Issuance - it’s not explicitly mentioned but the issuer is free to issue delegated credentials and there should be nothing in the spec that restricts this. If there is anything that seems to suggest delegated credentials aren’t possible please do raise an issue pointing out the relevant bit of text. Concerns for users and verifiers are totally in scope for DCP WG (albeit today’s call was very focussed on issuance, I expect we’ll get back onto presentation issues next week).

  9. Tom Jones reporter

    the problem with delegate versus holder only is the proofing process. The subject is not the one that is asked for the cred or who is proofed by the verier. The particular problem I have with DCP is their orientation to the VC and VP. I do not want a query language discussion as a part of the existing DCP meetings. If that is what Joseph is suggesting, then i will go somewhere else to discuss this where they are not worried about the sunk cost of existing trials. My #1 goal is a wallet that is easy to use by regular people, including underserved populations.

  10. Tom Jones reporter

    I read Mike’s view of the PE issues and one thing really sticks out, so i guess we should talk about that up front. The idea since SAML was that claims were the primary data elements that were requested and provided. I am proposing that purpose be the primary element requested with individual claims as a optional subset of purpose only if absolutely necessary. The primary issue AFAIK is user consent and not developer convenience. If OpenID does not agree that user consent is the one important part of a verifier-wallet request, then there is no need for any further discussion.

  11. Joseph Heenan

    Hi Tom

    I don’t think I understand what meaning “purpose” has here. What are the key differences you see between requesting a purpose of ‘ao.13' (as per the doc you link above) versus requesting a claim of ‘age_over_13’?

    User consent is a key part of the verifier-wallet request, and something the DCP & WICG working groups are taking seriously. It is mentioned in both specs.

    “The particular problem I have with DCP is their orientation to the VC and VP. I do not want a query language discussion as a part of the existing DCP meetings. If that is what Joseph is suggesting, then i will go somewhere else to discuss this where they are not worried about the sunk cost of existing trials”

    It is very hard to figure out what point you are trying to make here. As per the discussion on https://github.com/openid/OpenID4VP/issues/112 the DCP working group is happy to consider switching solutions if they current existing solutions have problems. I thought you just wanted to define a new query language - are you suggesting that you want to invent an entirely new protocol between the verifier and wallet that is not in any way related to the existing OID4VP specification?

    ‌

    ‌

  12. Tom Jones reporter

    as i described on the other thread - the user must give informed consent. I don’t see any description about turning and data base query into informed consent. My proposal was to give the user the choice, in the case of ao_13 the wallet might have additional requirements to assure that the user was actually old enough. In that case it is not sufficient for the person at the keyboard of their mother’s computer to use their mother’s wallet to say they were old enough.

  13. Tom Jones reporter

    i have decided to give up on this. I think the wallet experience will suck, but that seems unavoidable at this point.

  14. Log in to comment
Assignee
–
Type
enhancement
Priority
major
Status
resolved
Component
Basic
Milestone
–
Version
–
Votes
0
Watchers
1
Jira Software: the preferred issue tracker for Bitbucket. Join the team!