Skip to content

2023 11 06 Meeting Notes

Jump to bottom
Tim Cappalli edited this page Nov 9, 2023 · 1 revision

2023-11-06 (A Call)

Last meeting’s notes All meeting notes

Reminders:

WICG member: https://www.w3.org/community/wicg/

W3C Code of Ethics and Professional Conduct: https://www.w3.org/Consortium/cepc/

Please use the meeting’s Slack thread for discussions instead of meeting chat

Organizer: Tim Cappalli

Scribe: Heather

Meeting thread on Slack: https://w3ccommunity.slack.com/archives/C05UG0EJUDB/p1699228207757779

Agenda

Attendees

  • Tim Cappalli (Microsoft Identity)
  • Heather Flanagan (Spherical Cow Consulting)
  • Nick Doty (CDT)
  • Loffie Jordaan (AAMVA)
  • Brian Campbell (Ping)
  • Rick Byers (Google Chrome)
  • Lee Campbell (Google/Android)
  • Ryan Galluzzo (NIST)
  • Andrew Regenscheid (NIST)
  • Andrew Hughes (Ping)
  • David Zeuthen (Google)
  • Martijn Haring (Apple)
  • Ben VanderSloot (Mozilla)
  • Paul Batian (BDR)
  • Kristina Yasuda (Microsoft)
  • John Bradley (Yubico)
  • Joseph Heenan (Authlete/OIDF)
  • Dirk Balfanz (Google)
  • Hicham Lozi(Apple)
  • Jan Schill (unaffiliated)

Notes

(Tim) administrivia; no new attendees

(Tim) updates on incubation? Nope

Method naming concerns

(Nick) in the naming, request identity seems like you’re going to get back the person’s identity and everything about them. That could be a lot of sensitive, permanent information. The intent is that the API should be good for just getting back individual claims or properties. We want to design the API so it’s natural for the developer to ask for and expect minimal things.

(Tim) this came up in the last FedID CG call as well as they are trying to name the WG (claims vs assertions vs identity). Eventually we’re hoping this work is going to move to that group in a phase 2, so interesting we’re having the same discussions now.

(Lee) so, changing it from request identity to request attributes sounds good.

(Rick) agreed. Setting the expectation that the majority of use should be for things like “age over 18”. Tricky that it’s one method to do both asking for little bits and asking for everything, but we don’t see a way to split those apart.

(Tim) are these ultimately claims by an issuer?

(John) yes we should encourage people to ask for only necessary claims, but there are claims in the context of some credential (e.g., over 18 from an eID is necessary in some cases, in other cases over 18 claim from your gym). Claims are only useful in the context of an issuer.

(Martijn) maybe identity attributes?

(Tim) get identity attributes, get identity claims, get identity attributes?

(Andrew) if possible, don’t use the word identity. It’s not identity. It’s data, attributes, or claims.

(Lee) could non-identity things come over this API at some point? Room keys, concert tickets, etc? Those aren’t identities, they are things you hold. So, tested claim, verified claim.

(Tim) to future-proof this, is a concert ticket a claim?

(Lee) yes, it’s signed by Ticketmaster and issued to you.

(Rick) should debate get vs request. Not worried about making it too short. Like that request may or may not be satisfied, where get implies it always will be.

(Tim) and you may only satisfy part of the request depending on what the user consented to.

(Brian) call it request.

(Tim) any other comments? Nick, are you ok with this?

(Nick) hope this is useful back to API proposers.

(Ben) flag that the induced demand is why the word identity is being included; something to keep in mind

(Lee) like the idea that there is a tested or verifiable in some way, that it’s signed and not just autofilled. If you can get that notion in there, e.g., get verifiable attribute, that would be nice.

(Andrew) isn’t that a parameter or descriptor of the claim or attribute? How do you know who judges verifiability? Is it part of the format? We’re asking for a signed object; whether it can be verified is a different question.

(Tim) request signed claim?

(Lee) not too worried about it; it’s already a massive string

(Tim) will add these ideas to the issue, two week pending closure

Reason for request

(Tim) may have been in the early discussions and dropped in latest proposal. Nick, do you have concerns?

(Nick) Concern is that a fundamental part of a privacy protection is that the user understands what’s being requested and why. Passing it on as an opaque protocol-specific string, seems like it doesn’t encourage the developer to explain it in the use of the API and none of the protocols we’re referring to have a place for explanatory information. Would make sense to put it in the API between the site and the browser. That’s the moment when you wan the developer to explain the purpose for this thing.

(Rick) what’s your thought on how rich the explanation needs to be? An enum of 10 things or a complex ontology with different legal implications for different values?

(Nick) that’s a longer process/question for us to go through. It’s more than purpose. If we’re talking about info important for a user making a determination or the information managing the accountability of whether something is being requested appropriately, then we need something about purposes (used, shared, retained deleted), who is asking for it, legal basis, etc.

(Lee) main concern is where it gets displayed. Worried about arbitrary strings from random website into system UIs. Makes it look like it’s the system’s fault/responsibility. Don’t want to make claims we can’t verify. Maybe this is handled between the verifier and the issuer?

(Tim) many of these use cases wno’t have communication with the issuer

(Lee) that’s the issuer saying “I don’t care who is asking for this.” But if the platform is enforcing, then the platform has to check if the RP is being honest.

(John) one reason we want verifiers identified to the wallet is because they may have trustmarks from governments or other third-parties that will let them assert they are processing data to a certain requirement. The issuer gets to decide what wallet it puts credentials in in the first place. It’s the wallets responsibility …

(Rick) agree with John that it’s more the role of the wallet. The platform has a role in making sure the wallet is well designed, e.g., that it has a transaction log. Maybe we should be adding things to the API even though they are opaque to us so the wallet can provide the UX we’d want. We might be able to resolve the system UI concern by having th eAPI point to something in the web page (e.g., a DOM id, a privacy policy URL)

(Lee) I’m ok if this is in the wallet, and if it’s a redirect back to the issuers website. As long as it’s clear where it’s coming from

(Loffie) we had the same discussion in WG10 when we added the intent to retain flag. We realized there is a need to include more than just a need to retain. There is no standardized way to do it (but one would be nice) so the holder is not overloaded with information and they could make some decisions in advance.

(Martijn) to Loffie’s point, doing this programmatically seems more helpful and stable, but also strongly tied to exactly what the request looks like. Descriptors of mandatory, provisionally mandatory, etc. The request structure isn’t something we’ll have one thing for. Having it in a layer between the request and the website is tricky; better to do it at the request level or you have multiple places where the info can be provided

(Tim) we are almost talking about two classes of data - info for the user and legally bound stuff. If we’re talking age proof, the user should know why age is part of the request.

(Lee) are we thinking a description at the top level of the request, or are you thinking at the level of every attribute having its own description of why it’s needed.

(Tim) PE - you can an entire one for the request or one per individual

(Nick) I noted in the issue that it might make sense for both. If privacy properties depend on selective disclosure, will need to be able to explain that per attribute. But bigger picture is also necessary

(Lee) this is info we are passing to the wallet because it’s hard to do for a full UI; the wallet will know what’s relevant to it.

(Dirk) Bring up the parallel to the OAuth mechanism - how should the receive of the data add info so the provider of the data can add info for the user. We always end up not doing that because having the provider say something on behalf of the receiver seems weird. If it’s system UI or some other entity says something that another entity wants said, then that other entity should just say it. We do have a link to the privacy policy in the OAuth consent screens. There’s a lesson to be learned here.

(Ben) Delegating to Dirk’s expertise re: If you want to allow passing of info from verifier to wallet. The responsibility is for the page to say what it needs. If the browser can’t validate the info then having the browser present it implies validation to the user.

(Tim) re: OAuth, in FedCM it gives you at least some idea of why this is happening. It is giving user context as to why something is happening (sign in/sign up). What is the equivalent here? What does the user understand when the browser pops up? FedCM does allow additional context to be added. It would be weird from an OIDC request has richer context than from other protocols.

(Nick) understand the concern about presenting misleading info in the browser UI. We should learn lessons, but I may have learned different lessons. The failure over the last 15 years of explaining what’s happening to the user and why. Users now ignore or deny what’s presented to them because they have no background of understanding. The current situation has led to no presentation whatsoever and therefore no accountability.

(Ben) responding to Nick: if there is a clear way to design the UI to make that idea work, that the site is presenting a claim of X for this thing seems reasonable

(Kristina) want to provide context that protocol specific request don’t allow site authors to indicate how info will be used. OpenID for VP has ways to do this. Would like not to reinvent this outside the protocol. Information can be signed by the verifier if it’s in the OpenID for VP request string. That adds trust to the privacy policy, terms of service, etc.

(Rick) maybe we’re conflating two things - user understandability at time of action and accountability. We should be able to provide more information to establish accountability, and maybe features to encourage that can be turned on in the browser itself. E.g., a log of who asked for what and when. We could design the API so a browser that wants to have those features could have it. That doesn’t mean it has to be at the top level. This group is talking about opaque protocols, but the browser will understand them; they won’t implement otherwise. Agree with Kristina that we don’t want to duplicate that.

(Tim) operating on the assumption that the wallet is the same as the browser in terms of trust, but users won’t necessarily trust every wallet the same way.

(John) remind folks that the responses from wallets are going to be encrypted and opaque to browsers no matter what browsers want. It’s the role of the wallet to provide that sort of logging.

(Tim) that’s my point - when the user selects a wallet, all bets are off. so the user needs as much context as possible before the user selects the wallet. (John) completely disagree. The purpose of the selector is to find a wallet that can satisfy the criteria. Then it’s up to the wallet to decide what info can be shared and get the consent of the user. How does the RP’s privacy policy indicate what attribute being requested

(Tim) we are asking the RP to tell the user what’s being requested and why. In FedCM, the website is requesting you sign in, and that’s still some context.

(John) if we want to provide that minimal level of context, then perhaps we get back to the limited number of enums that the selector could provide as additional context and leave the rest to the wallet. But any free-form text to the verifier displayed in the selector isn’t a good idea.

(Tim) an enum is a good solution

(Lee) there are two things going on - human readable strings that must be simple and info for retroactive accountability, and these things need to be split out. Nutrition labels for retroactive enforcement. Your justification for the request may or may not be displayed, and per-attribute, human-readable justifications could be more user friendly and displayed somewhere.

(Tim) Good framing

(Nick) the terminology is a layered notice, and that can be really valuable for most users wanting really high level, and others wanting something more low level. Would caution us against having one that’s only visible to humans and one that’s not. If you’re going to go to your regulator to talk about accountability, the regulator will say “what matters is what was presented to the user that informed their decision.”

(Lee) it could be shown but the spec won’t mandate that it be displayed

(Martijn) agree with what Kristina said; we should handle these at the request level and not the browser level.

(Kristina) following up on if we can clearly differentiate the consent screen rendered by the platform and the wallet itself. We do not want to replace the wallet consent screen with the platform consent screen. That would discourage wallet from handling credentials. We do want to give user to have enough info to choose a wallet, but let’s not overload the consent screen because we want to leave benefits for the wallet management screen as well.

(Nick) thanks for the point, Kristina, about how some of the requests protocols have that information available. One concern - sometimes things can get out of sync. We have explanations in different places, and we do not want that in conflict with what they’ll see in the wallet. We want the explanation in the context of what the user is doing.

(Tim) will keep the issue open for discussion

Credential selection vs. wallet selection

(Kristina) no intention to block that issue from being closed, but if people can take a read, that would be helpful. There is still a question of whether the API is a credential selector. I think we’re talking about a credential-based wallet selector.

Clone this wiki locally