- From: CCG Minutes Bot <minutes@w3c-ccg.org>
- Date: Mon, 10 Mar 2025 17:01:47 +0000
- To: public-credentials@w3.org
Thanks to Our Robot Overlords for scribing this week! The transcript for the call is now available here: https://w3c-ccg.github.io/meetings/2025-03-04/ Full text of the discussion follows for W3C archival purposes. Audio of the meeting is available at the following location: https://w3c-ccg.github.io/meetings/2025-03-04/audio.ogg A video recording is also available at: https://meet.w3c-ccg.org/archives/w3c-ccg-weekly-2025-03-04.mp4 ---------------------------------------------------------------- W3C CCG Weekly Teleconference Transcript for 2025-03-04 Agenda: https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Mar&period_year=2025&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date Topics: 1. <Digital Credentials API> Organizer: Harrison Tang, Kimberly Linson, Will Abramson Scribe: Our Robot Overlords Present: Harrison Tang, Tim Bloomfield, Mahmoud Alkhraishi, Nis Jespersen , TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), Emily Lauber, Rob Padula, Joe Andrieu, Greg Bernstein, Benjamin Young, elf Pavlik, Vanessa, Andy Miller, Guest, Heather Flanagan, Phil Long, Manu Sporny, Tim Cappalli, Susan Stroud @ Lifequipt, Samantha Matthews Chase, Jeff O / HumanOS, Jennie Meier, James Chartrand, Nate Otto, Erica Connell, Dmitri Zagidulin, Will Abramson, David Chadwick, ?, Allan Third, Alex Higuera, julien fraichot, Matthieu Bosquet, Kayode Ezike, Matthieu Collé, Juan Caballero, Geun-Hyung Kim, Aaron Our Robot Overlords are scribing. Topic: <Digital Credentials API> Harrison_Tang: So welcome uh welcome to this week's ccg meeting so today we're excited to have the team and Sam actually here to present our digital credentials API but before we get to the main agenda I just want to quickly go over some administrative stuff so first of all a quick reminder on the call to pass the exam professional contact I just want to make sure that we hold our respectful and constructive conversations here. Harrison_Tang: All right next uh a quick note on the intellectual property anyone can participate in these calls however all substantive contributions to any work items must be member of the ccg with full IPR agreement signed so if you have any questions in regards to the w3c account or the IPR agreement uh please feel free to reach out to any of the cultures. Harrison_Tang: Uh a quick note about the call uh these meetings are automatically recorded and transcribed and we will uh publish the transcription the audio recording and the video recording in the next day or 2. Harrison_Tang: These uh GG chat to cue the speaker so you can type in Q Plus to add yourself to the queue or cue minus and I'll be moderating the queue. Harrison_Tang: All right next uh just uh want to take a quick moment uh for the introductions and the introductions so I know there's a lot of new faces here uh if anyone's feeling brave uh feel free to just unmute and introduce yourself. Harrison_Tang: All right I know a lot of people can't wait to get to the main agenda so I'll go to the next. Harrison_Tang: Next agenda uh announcements and reminders uh anyone have any new announcements or reminders money please. Manu Sporny: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2025-02-26-vcwg#resolution1 Manu Sporny: Uh yeah just a couple um the first 1 um I'll put the link in the the chat Channel but um for those of you that weren't aware the verifiable credential working group uh resolved to transition I think 7 specifications to uh the proposed recommendation state so this is the the completion of the verifiable credential to a work um a by and large uh we are hoping that the transition happens around March 20th with a full Global standards for all 7 of those specifications happening mid April uh sometime so that's on a good Glide path in the group has basically finished its work on those specifications so that's good news but that of course raises the question of like okay what are we going to work on next um there has been a. Manu Sporny: Is now meeting uh on kind of the Next Generation data Integrity stuff I'll put a link uh into the chat Channel. Manu Sporny: Um so these are the data Integrity meetings. <manu_sporny> Data Integrity meetings: https://lists.w3.org/Archives/Public/public-credentials/2025Feb/0056.html Manu Sporny: And we are largely focused on privacy preserving uh uh cryptography Suites uh and post-quantum uh Suites there's been quite a number of people uh that are showing up to those meetings so that's good and that's incubating work that will go into the next Charter um there is also other work uh that is being incubated here that we probably need to start having meetings on around uh render method confidence method um uh uh The Selective redaction uh you know crypto sees stuff like that um and so we might send out an invitation to a new meeting series just to finish up incubating that work before we move it on to the bcw so uh again thank you to everyone um on all the great work incubating stuff uh here so that the verifiable credential uh working group can uh finish up uh the work on the standards track uh that's it for me. Harrison_Tang: Thank you man. Harrison_Tang: Other announcements were reminders. Harrison_Tang: Any updates in regards to the work items. Harrison_Tang: Family Man are there new developments to the confidence method and branded method that maybe I can invite uh the people to present the latest developments. Manu Sporny: No I mean yes and no uh yes uh there's been a lot of movement but no like the various people moving those things forward haven't gotten together to come up with a cohesive narrative so it might in in 2 or 3 months maybe um but but short term probably not I don't know if that answers your question. Harrison_Tang: That's great thanks. Will Abramson: Sure yeah I guess I want to speak to this like it's right like it would be great to kind of Kickstart these efforts I think with confidence method we see like an effort of like like a work item that kind of like like at least in terms of the ccg is stagnated right and I feel like there's not a. Will Abramson: An owner of that works currently I think it would be good to like use you know if we're gonna kick up these new streams of work it'd be good to maybe rethink how those streams feed back into this group in a more regular Pace uh. Will Abramson: I just. Will Abramson: That's the flag for us all to think about how it might help these work items keep um energy. Harrison_Tang: Just a quick uh reminder so next week we have the uh open meeting with work ID updates and uh quarter 1 2025 review so uh you know for different uh project leads uh please feel uh please uh help us update that deck that I sent out so thanks. Harrison_Tang: Right any other uh. Harrison_Tang: Things in regards to announcements reminders work work items. Harrison_Tang: So a quick note on the on the technical things in regards to this call so uh if uh later uh you know if the presentation got very big and people got kicked out. Harrison_Tang: For me to just uh refresh the browser and rejoin uh everything should work uh uh you know without any issues uh actually the culture has been looking to uh transferring the call to zoom uh but uh we you know we're still trying to figure out the the details because uh none of the cultures has the admin access to w3c zoom account so we're still trying to figure out how we can do that. Harrison_Tang: All right let's get to the main agenda so uh today we're very excited to have a team in kapali from okta San go from Google and actually Heather uh who cheers the family identity group to talk about digital credentials API um a quick note uh there's a. Harrison_Tang: Uh Federated credentials management API which is uh more about uh browsers uh you know basically uh you know the original premise is basically uh uh get the browsers uh to support Federated identities and single sign on uh without the cookies third party cookies and digital credentials API. Harrison_Tang: Actually accessing uh the credentials within a wallet uh so on today's session is mostly about the digital credentials API and I think that can 17 can go into more further details so very excited about this thing because I personally think I think a lot of you guys heard me talking about how I personally think this is actually uh 1 of the biggest opportunities uh to drive market adoption uh for self software identity so thank you uh in advance team and Sam for jump now. Tim_Cappalli: All right uh just a quick audio check can you hear me. Tim_Cappalli: Okay awesome um hi everyone uh thanks for having us today um we're gonna present as if you've never heard of the digital credentials API just to to help level set um there's a a lot of history here going back we're almost on year 4 it seems it well it doesn't seem it is year 4 um so we'll go through the background how we got here um kind of where where things are at um some exciting news about how the work will progress and um if we have time at the end we'll wrap up with a little comparison of you know the DC API and fcm um they're they're they're separate but you know some of the um end States uh align closer than many many uh many things so uh we we will talk about that. Tim_Cappalli: So to start on the background and design goals and feel free to interrupt let's make this a conversation um so feel free to ask questions as we go um I think as as you're all very familiar with right we have kind of 2 generations of problem the first generation was how do you actually present um especially real world identity documents but anything that is in the physical world um to a website right and that really meant um up until recently and Still Remains for many sites holding a document up to a webcam I literally had to do it last night to bootstrap a new device and it's just the most infuriatingly awful experience um and um you know you scan the document you do a live check um most people have to scan it 2 or 3 times because you know you're trying to align to a webcam that is um. Tim_Cappalli: why is my. Tim_Cappalli: Keep going off. Tim_Cappalli: Speaking of its weird um uh you know you keep having to align it to the to the frame and make sure the mrz is visible and all these fun things No No 1 actually really I I shouldn't say no I hope no 1 actually enjoys this experience but maybe there's someone out there um so then then came right verifiable digital credentials and and being able to present them on the web but that meant Uh custom schemes and QR codes right that's kind of been the status quo um for a number of years now um which have very poor security properties and a and a pretty bad user experience as well um so we've made some progress on the digital format of these documents but um the presentation got slightly better but with a lot of room to improve um so custom schemes you know these are just a I assume everyone knows what they are these are a few that are out there um they're unpredictable they're not standardized um they lead to very poor experiences here's a few um this is actually even at a date I went and found this list um last July so I'm sure there's more if you notice right people keep just adding to the left or the right. Tim_Cappalli: right to make them more specific. Tim_Cappalli: Try to have a more predictable experience um but you know you're just continuing to Kick the Can um and waiting for things to break again. Tim_Cappalli: So some of the challenges with custom schemes um right that you you can invoke invoke them from an insecure context right that could be a page served over hdb um it could be an app using an insecure channel right there's there's no binding to an actual um a a secure context whether it's on the web or on the app platform you can actually fish users via app selection right so we move you know we have fishing on the web largely solve for authentication but now we have like this app fishing problem um because you know any app can can register and claim uh uh to to to be the uh request of this um if you notice in the screenshot this is just a mockup right it does use the normal Android uh disambiguation UI but I kind of added some wallets there in Photoshop so doesn't look exactly like this but it probably should look familiar you'll notice there's like no request or or identity right who who actually is making this request it's just asking me to complete an action I have no idea who actually asked for this. Tim_Cappalli: I mentioned at the beginning it's not standardized right there's no it's actually very hard to find a formal definition for custom schemes because it's just kind of something that's always existed um and you know continues to cause issues. Tim_Cappalli: Know you know there's a context switch for the user right so when I tap on a link in a in a in a website or in a service you know it just kind of takes you out of out of that context right usually it takes you to the other app after you select it and there's actually no real easy way to fall back from that if there's an error both success and error right so once I pick an app on the screen go to the app like you really can't get back easily and there's not a great way to share State as well. Tim_Cappalli: Uh and the last big 1 which I think should be very clear from this screen this this uh screenshot right it's a very very poor ux for credential selection right you users don't understand wallet selection right they don't even know what a wallet is write a wallet is just an app um and so asking user to make a decision based on this information is just is just you know not not realistic for most users. Tim_Cappalli: Um so a lot of this work kind of took the learnings from pass keys right as we rolled out pass keys I Was A New Concept for users you know web authentic Pho have been around forever but it was really in the work context there wasn't a ton of um usage outside of the workplace um and so you know users think users don't think about their authenticators right authenticator being their security key or or bit Warden or Google password manager right they don't think about that they think about the account or the credential itself right like like a user does not necessarily know where they store each individual thing maybe they say oh I store most of my stuff in 1 passwords. Tim_Cappalli: Apple password right like you don't think that way they think about the account they're trying to access or the individual credential. Tim_Cappalli: And the other piece is call our context right as I mentioned with in the previous uh screenshot there there's no context there this you know with a when you use a pass key it's very clear who is asking right it's a website or an app named that's very clearly presented um and the last 1 is that cross device right so being able to present from my phone which is where a majority of wallets in the near-term are going to exist uh to your desktop to access a service in a browser or in the native app platform that has to be easy to use and it has to be secure and resistant to phishing right and that's another thing that came from. Tim_Cappalli: Uh the pass Keys effort right is we solve that cross device uh flow with a you know it's not as it's not as easy to use as obviously if the credentials on your local device but we think it's a it's a good experience for those fall back scenarios where you don't have a credential on local device and it's secure and resistant efficient. Tim_Cappalli: So as this work started um there's some Core Design principles that were uh you know agreed upon in the group that um you know is the ycg and some IBEW sessions and other things um to kind of figure out where these boundaries are between what a web API would look like and kind of the rest of the ecosystem and the 4 um I would say most critical design principles were separating the active requesting um the specific protocol um to allow for flexibility in Pro protocol and credential formats right so um browsers can evolve protocols can evolve and they won't necessarily block each other right that was a very very very early very loud and clear request from The Wider community of of of of how to build this in in a way that was extensible and and non-blocking. Tim_Cappalli: Uh the other 1 is require request transparency right so the you the browser is the user's agent where you know this is a w3c call I think I think we're all very aware of that um and the browser needs to do as much as I can to protect users from risk um so having the requests that's passed into the API uh be be visible to the to the browser to potentially put up a speed bump saying are you sure even um is is really important but assume that the response right so the the presentation is encrypted um to the verifier right um so that um allows the verifiers and the holders to control when pii is is exposed so request unencrypted response encrypted that's the Assumption you don't have to uh encrypt the response if you don't want to but that's kind of the design assumption. Tim_Cappalli: Um and the last 1 similar to um web authent and pass Keys uh present web present a website. Tim_Cappalli: Prevent a website from silently querying for the availability of credentials um and communicating with credential providers without explicit consent right so that's a similar Paradigm um in the web authn world right you can't just probe to see if there's an authenticator uh a specific authenticator or a specific credential available um that's just a pretty big fingerprinting service. Tim_Cappalli: Any questions before I move on here. <?> an array of these things... Tim_Cappalli: All right so in terms of how the the the the the layers all interact here right in the different components um with the digital credentials API to the left um the API itself as we'll see in a minute is very very simple right uh it takes in a protocol um and a protocol string uh and a request object um and so the 2 protocols that are are are used today um and you know we've been working between the different communities that Define these protocols our open ID for VP for presentation and open ID for VCI for credential issuance so the API can take in and oid for VP or VCI request object um and inside of that you know if we keep going down um there it's also credential formatting agnostic right so you can use open ID for VP with ISO endoc or open ID for VP with SD chop VC the API itself is agnostic to all of that right it just needs to know the protocol string and a request object. Tim_Cappalli: um you'll. Tim_Cappalli: At the bottom it's open. Tim_Cappalli: For others right this is designed to be extensible the the spec has a registry um and 1 of the things I'll talk about later is how do we actually get new uh entries into the into the registry. Tim_Cappalli: All right I see some questions sorry the transcription thing is very distracting. Tim_Cappalli: Uh who is first. Tim_Cappalli: Oh you are oh okay sorry I thought I saw a question um. Tim_Cappalli: Uh Sam and Sam just chime in more um. Tim_Cappalli: in terms. Tim_Cappalli: Of real responsibilities this comes up um a lot and I'm going to turn my camera off so you can see the bottom because I think it's. Tim_Cappalli: Um there there's essentially in in this here right there's 3 there's the browser the OS platform and the credential provider and obviously the user is off to the side but from a from the the technology stack standpoint um and wants to talk about kind of the roles and responsibilities of each of these and what is not is and is not in scope for each of these right so the browser operating on the web as the web platform obviously provides the API service to developers does some basic request validation right like you need to build an error out if you if the developer sends in a bad request uh it does all of the existing secure context checks that happen um with other apis right like in web and you can't can only call Webb off and in a secure context same thing here that also allows for providing the origin because the you know TLS authentication is a server authentication has a curve with the origin um again very very similar to web authn um and the browser also handles the interaction with the underlying OS platform right so to talk cell phone into the platform the browser needs to know how to communicate itself though. Tim_Cappalli: On the OS platform. Tim_Cappalli: Side um the OS platform is responsible for a credential selector for presentation and a provider selector for issuance right that that's where the big differences between presentation versus issuance during presentation um there's a little bit more intelligence right there's you know parties can work together to to to uh provide more context to the user whereas during issuance very similar to pass Keys you you have to ask the user where they want to put it right that there's not not a whole lot of other ways around that um so that's the you know slight difference between the presentation experience and issuance experience the OS platform also handles cross device transport um so actually getting the getting the presentation from my phone to uh let's say browser on my laptop. Tim_Cappalli: And the OS platform also handles native app requests right so um similar to the web authn API there is a um. Tim_Cappalli: A native app abstraction um of the API on the app platform. Tim_Cappalli: Happens to on Android for example mirror I think it's actually identical um the web platform API off of cred man um and that allows a native app to also uh do a presentation or issue and request uh through a similar API. Tim_Cappalli: The 1 thing that's common between the browser and the OS platform is a permission check you know we're explicitly saying permission not consent write permission to continue and disclose the request to the next party right so I I'll show a screenshot in a minute there's a clear line between where the wallet gets notified of the requests because even just a request can be privacy invasive um for the user especially if you phone home and tell others about it um so the permission we're explicitly using the term permission um whereas the wallet or the credential provider is what is in charge of holder consent very you know 2 different pieces there. Tim_Cappalli: The other things that the credential provider handles which I'm sure you all know holder verification right Biometrics pin all of the presentation and issuance protocols get implemented in that uh application so that in clarifier and RP authentication selector disclosure signing encryption all that fun stuff and then Key Management right so a majority of the the things are still left up to the credential provider. Harrison_Tang: Sorry a couple uh questions uh first of all a quick clarification question is that for digital credentials API does it has to go does that. Harrison_Tang: have to. Harrison_Tang: Go through the browser or can can the an app just interact with the app Wallet through the OS. Tim_Cappalli: Yeah so so um like like like with web authn right like the the w3c digital credentials API right once it gets that status is the web platform definition of it which is often mirrored into the app platform that's not required obviously there is there's no standards beliefs for the app platform um but it happens to be that the current implementations that are out there mirror the web platform API 1 to 1 so you can make the same requests to the OS natively if you're a native app as you would to uh through the web as a web verifier. Harrison_Tang: Money the next thank you. Manu Sporny: Yeah thanks Tim this is great uh as always uh really appreciate the like um uh really clear narrative on on uh you know kind of what what's going on here I'm I'm looking I'm wondering what the latest is on uh kind of the OS uh in uh browser platforms is there is there full agreement at this point about these being the roles and responsibilities and there being like true uh you know app Wallet selection or or there any rough edges left there or do we feel like you know Apple and Google uh and the Samsung effectively agree that um these are kind of the foundational parts of the. Manu Sporny: The the roles and responsibilities for the OS and browser platforms. Tim_Cappalli: Yeah I I don't want to speak for any of those companies but there has not been negative uh no nothing negative is brought up about this architecture right so we you know if you you can actually see some of the um you know the the browser engine code for some other platforms and maybe have not announced announced support yet um and it very much mirrors this web whether they call it for example a selector or like the terminology obviously it might be slightly different um but the concepts do seem to line up and Sam might have something to say here as well. Harrison_Tang: Send you have something to add. Harrison_Tang: Money do you have a follow-up question I know we go go to dimitry. Manu Sporny: A follow-up statement because I don't want to put Tim and Sam on the spot so I'll just make a statement you know I I think that's that's great that you know regulation is playing a part in um how this is deployed I think this actually gives us a path forward to True uh kind of uh wallet and app selection um I am wondering out loud um uh how these apis might be implemented in uh countries where that regulation doesn't exist so for example uh what we could see is that you know the European Union does have true app selection but for example the US ends up not having it because the regulations uh weaker um in in the states so uh again not asking for anyone's opinion on that just highlighting that as you know potential outcome I think the work that's being done here is just really fantastic and great and is the closest we've gotten to you know true true wallet and apps selection uh ever thanks. Dmitri Zagidulin: Question about the affordances of the mobile API as far as identifying the request origin to the user right so for the web we have the the actual domain origin so we can say website.com is requesting a credential what's the affordances for the apps are we able to identify is the OS able to identify the apps I mean presumably yes and how does it um how does that identify the app to the requester. Tim_Cappalli: Sam I believe it's the same as what about then right where it's an APK hash of the binary. Dmitri Zagidulin: And does does it present the the name to the to the US. Dmitri Zagidulin: Sir okay got it. Tim_Cappalli: The UI definitely shows the name um but I believe like the origin that's passed to the like in the API let don't quote me on this I will follow up but I believe it's going to be the APK hash just like web authn on Android and I assume given. Tim_Cappalli: Apple platforms don't use APK hash they map it to a web origin I I would assume that would be the pattern they would follow but I can't speak for them. Dmitri Zagidulin: Got it thank you. Dmitri Zagidulin: Yes the requesters the the relying parties. Dmitri Zagidulin: Right yeah so I was curious about the mobile side. Tim_Cappalli: I'll I'll get an interview by the end of the call I'm pretty sure it's going to be the APK hash like what. Dmitri Zagidulin: Thank you so much. Andy Miller: Yeah thanks the um was it something that I'm not sure about from here is the verifier does the verifier get a sense of the wallet. Andy Miller: Uh the wallets I did I I use identity Loosely here there may be another term for it but like well the the verifier need to know the wallet in these like in web authentic it's not really that important what the provider's identity is we've been able to move past that but what is that like here in the DC. Andy Miller: Okay so if that's a protocol. Tim_Cappalli: Right I mean the only the only. <zacharias_törnblom_third_attempt> EUDI when using digital credentials api will require specific wallets Andy Miller: Okay so that could that would be orchestrated through the protocol as opposed to and and DC API has no influence because DC API is basically a funnel for the verifier to talk to the wallet okay. Andy Miller: And turning over. Andy Miller: Yeah that makes sense that that comes down to the choice of protocol used over the DC API and whether or not that allows the verifier to know the holder's identity. Andy Miller: Okay thank you very much. Tim_Cappalli: Uh Demetri I already got an answer yes it's on Android it's the APK hash just like used with web authent. <dmitri_zagidulin> thanks Tim_Cappalli: Is that all. Harrison_Tang: All right I don't think and yep that's everyone. Tim_Cappalli: All right all right so let's continue on um uh you may have seen this diagram before I I reuse it a lot um in terms of the protocols we're talking about right so the digital credentials API uh operates in the browser context right so that's this uh stop sign looking box um the other standardized protocol that is in use with this whole experience is um reusing actually the phyto cap 22 protocol um which actually was modified to it it 22 started with uh adding support for cros device uh with pass Keys uh and we also modified it um late last year to support uh a digital credentials request as well um so um anyone any platforms that support uh ctap 222 uh once it you know it's it's actually a final now the board approved it um they will just need a quick update to support the DC API uh and now they can do cross device uh presentation as well um so those are the 2 you know the the blue line and the or the middle line I should say and then the the lines coming off the verifier. Tim_Cappalli: You know standards based protocols and then the purple lines are ultimately the app app platform abstractions that exists um to to to support the individual um apis on the OS. Tim_Cappalli: Uh these these diagrams uh I'll I'll put a link I thought I had on the slide but you can find these in the DC API repo um it just kind of goes through like who is involved what is happening what apis are used so in this example um this is a same device scenario with a web-based verifier and a native app wallet so the verifier can you see my mouse. Tim_Cappalli: it's hard for. Tim_Cappalli: Okay sorry um so so in this case right the the browser renders the verifier site most likely gets a bunch of parameters from the back end um to to craft the presentation request the presentation request is passed into the digital credentials API the browser then may decide to show a quick prompt asking the user for confirmation um but typically it's going to then hand it off uh to the the app platform apis at this point um this is where the selection screen will pop up and I realize as I'm presenting we have actually shown that yet um but there'll be a pop-up that says hey you know these are the credentials we think you may want to present and here's what's being asked for and once the user hits continue on that line 4 it gets dispatched off to the the the wallet app the credential provider it does whatever it needs to it could just be a biometric check it it's probably going to be consent it may even be other things after the user has um allowed the wallet to take over the wallet can do anything um and then it you know uh packages up the response. Tim_Cappalli: and sends it. Tim_Cappalli: Back through that API. Tim_Cappalli: Call which then makes its way back up to the browser um in that response from via the platform API and then the digital credentials API promise resolves with the result of the presentation um for issuance it would be um a slightly different um but the the very very uh similar. Tim_Cappalli: And then the cross device flow everything is largely the same except to get from device a to device B um we use uh the phyto protocol to get the request over there and then the same component on the other device handles getting it to the wallet app it comes back response goes back over the uh C the the channel here and then goes back up to the verifier so very very similar just another protocol sitting in the middle to handle cross device. Tim_Cappalli: And like I said there's a bunch of these diagrams uh including uh native to Native uh that I'll link to at the end. Tim_Cappalli: In terms of the API I mentioned at the beginning it is it is very very basic right the the the API itself like the interface is very very basic um it hangs off um credential management just like uh web off end just like uh fedsmith um object which takes um a protocol and a and a data parameter right so the protocol is ultimately going to be mapped in the spec as a in the registry right and that protocol identifier is mapped to a specification right so the registry is is is inactive work area where we're working on in the spec text but ultimately the goal is to map um this type of request to a a specification somewhere else right uh and today that is open ID for VP that lives in open ID so the registry entry for this will say you know this string here open ID for VP V1 unsigned uh and it will point to a link to the other protocol and inside data right the term data is very generic by Design it's an object that takes. Tim_Cappalli: Request um and and that is defined by the protocol right so that is not defined in the digital credentials API is defined in the protocol and that's what the registry maps to. Tim_Cappalli: So you can imagine in this request I didn't put it here because it would be too small uh we're requesting family name given name and an age predicate um so all of the different open ID for VP parameters that would enable that would be passed and then you get the selection screen at the platform layer. Tim_Cappalli: Um so so coming up a little bit full circle on the problem statements we had right so in a presentation flow right we were missing who is asking uh we're missing what they were asking for um and we didn't really get any context other than the provider name before so now we have that right so this is the selector screen rendered by the OS um we are asking to if we can share our credentials with digital credentials Dev that's the origin um they are asking for a family name given name and an age predicate over 21 um and we have a very credential Centric view right it does say who can actually provide the credential in this case the wallet name is IC wallet but that's a very very small piece of of of the selection screen for the user right it's very credential Centric I do have a credential it's called Tim's driving license that can be these requirements and this is the info that will be shared um and as I mentioned uh earlier this is the example where the the wallet hasn't learned anything yet right so this is being rendered by the OS platform in a sandbox um and this sandbox. Tim_Cappalli: Provided by the wallet that runs uh essentially a matcher right and so by being in a sandbox um you you can't make any network calls for example right so by being able by rendering the selector you're still not able to let's say collude or send information to your back end um that could be used for like information gathering or or tracking a user right so uh until the user clicks continue here the wallet knows nothing the wallet is just essentially said to the OS hey here's all my matching code uh run the request against it um and anyone any wallet that can handle this request will then show up in the selector once the user is has again permission once permission has been granted uh by clicking continue now that's completely dispatched off to the wallet and the wallet is responsible for everything else including uh holder consent right so that's that's kind of the dividing line we have to probably find a better way to visualize this um with some new pictures but um that's that's really the key dividing line um and you know the browser is. Tim_Cappalli: largely out of. Tim_Cappalli: The picture it's holding a. Tim_Cappalli: Right like its it hasn't resolved the promise yet um it's just sitting there waiting for a response. Tim_Cappalli: All right uh just to show you this for real um. Tim_Cappalli: You've already seen this elsewhere but I'll do a quick demo um. Tim_Cappalli: My phone ready here. Tim_Cappalli: Can you still see my screen. <bumblefudge> i think that's a jitsi resource thing Tim_Cappalli: Okay those those were the dropped okay uh you can see my phone screen on top yep okay cool all right uh so real quick we'll do a demo just on on this device right this is just a normal there's nothing special about this device Android 15 Chrome 135 I assume at this point um and in this case this is a public demo site I'm going to request family name give it name and age over 21 and I actually have a wallet installed it's the oh open Wallet Foundation actually sorry this is um going to use CM wallet sorry I have so many Wallets on here this is just a sample wallet for the digital credentials API and in here I have a driving license sorry the UI is a little it's just for demo but I have a driving license for John Smith and an age predicate um and that is in my CM wallet and you'll notice I have other wallets installed um to show that you know only the wallet that has a credential that can match will show up and I'm going to go ahead and click request credentials now this is actually a chrome right this is this is an example of the browser optionally requesting permission. Tim_Cappalli: right this may not always. <kayode_ezike> I may have missed this, but how does a wallet register with the DC API, so that it appears in the wallet selector? Tim_Cappalli: Right it may be that yeah this is determined to be a high-value you know it's an Isom doc right so with a um. Tim_Cappalli: Mobile driving license right so this this may or may not show up it's the user agents Choice based on risk uh to the user um but this is a very basic 1 that's just saying hey like. <kim_duffy> Can you decline? Tim_Cappalli: We're we're about to ask you for some information so I'm going to click continue and in this case now the OS selector screen right so this is actually the mattress code is already run um and the CM wallet has responded back and said I can handle this request I have John's driving license um and it's asking are you you know you're going to be asked to share family name given name and age over 21 so I'm okay with that um if there were actually 2s here you'll see very very small at the bottom here there's a little dot you would actually see like a rotating like a cart selection um so that you could you could pick a different 1 in this case I only have 1 uh I saw in the chat can you decline yep I can just click off of it and now I'm done but again that's just a bad error for demo but um you can decline it yes and I'm going to restart it. Tim_Cappalli: And I'm going to click continue. Harrison_Tang: By the way 10 there's also another question in the chat which is uh you know how does the wallet register with the DC API and uh so that it appears in the wallet selector. Tim_Cappalli: Yeah I I'll answer that right let me just finish the demo and then I'll answer that um so in this case I'm going to go ahead and click continue in this case the wallet doesn't need anything other than a biometric consent likely to do the signing operation but you could show full UI here you could ask the user to do something um you you're likely going to ask for consent but in this demo it's just saying hey uh confirm your identity so in this case I'm going to do my fingerprint and now uh the promise resolves and the browser has gotten the 3 uh claims that were requested um and if you look in debug you'll see there was only 1 document um sent back in this case I didn't check the request encryption um option so it was not encrypted by the wallet um but if I did use encryption you could do that we expect most um government uh identity uh responses to be encrypted. Tim_Cappalli: Uh to answer the question about the how does the wallet register the OS so you essentially you write your matcher code right and that matcher code anytime the wallet gets a new credential uh so like an issuance process uh fit completes you're most likely going to update your metric code on the Fly and and there's a platform API you call to to essentially push your new mattress to the OS it's a little more detailed than that but that's the high level explanation of how it works. <kayode_ezike> OK, thanks <?> wait, request encryption ? <kim_duffy> Can you share the full payload that gets sent? Tim_Cappalli: Uh so now let real quick I will do a cross device demo. Tim_Cappalli: So same site let's see same site that I accessed on the phone. Tim_Cappalli: And I'm just going to refresh so it's the same request here so requests credentials same prompt you'll notice um and in this case since I don't have a local wallet it's a it's a desktop uh makes sense I'm going to get uh a QR code this is the cross device presentation flow I'm just going to scan it ignore the used Pass key that will get updated eventually um this is all still uh prega so uh it'll eventually say um I think it's gonna say present to credential or choose an ID uh TBD um I'm going to click continue now we're doing the standard cross device uh flow enabled by ctap 222 and you'll see the exact same selection screen that I got locally because the exact same thing is running on the device right so the match the matcher was called the request came into the OS the OS passed it off to the matcher um and this case I'm going to click continue I'm going to do the exact same thing as before the wallet uh returns to the OS and the OS responds back over the cross device connection and back and away we go to the verifier. Tim_Cappalli: So that all work this is all actually you can play with this um. Tim_Cappalli: We are working on getting uh digital credentials Dev no dash um updated with some of the newer stuff um you know that will be kind of the develop resource um but this is all there's nothing special about anything um I just showed these are all production builds um of everything. Tim_Cappalli: I think I saw another question come in as I was uh yeah sorry the request encryption that was a bad way to say that um requesting encryption in the uh here sorry that was a terrible way to say that so right here you'll see using encryption that's what I meant sorry requesting response encryption terrible way to say it. <?> got it, thx Tim_Cappalli: Um can you share the payload that gets. Tim_Cappalli: Uh I don't know if I have 1 here but yeah I I can it's it's it's in this case it would be the open ID for VP response right and and it would be data and then the protocol so it looks almost identical to. Tim_Cappalli: Uh sorry looks almost identical to this but um data will contain the response. Harrison_Tang: Kim you have a question. Geun-Hyung Kim: Yeah I guess I am interested in seeing specifics like you know of course the um. Geun-Hyung Kim: Potential for linkability things like that um just curious to see what is uh what's what's disclosed. Tim_Cappalli: Yeah so that all most of that is handled by the protocol itself right so the the API is just carrying the presentation response from open ID for VP. Tim_Cappalli: Let me see I I can't remember if we log into console let me do it 1 more time and I will see if it's shows it here. Tim_Cappalli: If you want to keep going with questions while I'm doing this I can answer and. Harrison_Tang: Demetri you have a question. <zacharias_törnblom_third_attempt> How much information is available to the device/os in the various steps of the request/response? Dmitri Zagidulin: I think the question many of us was mind is we have a chance to demo the the other flow the provisioning the issues flow uh because this is fantastic like I'm I'm super excited about this flow of requesting credentials I'm curious if there's any uh good news on the issue. Tim_Cappalli: Um yeah I will talk about that in a second I do not have a demo but I can send a video of it um after and I'll cover it just a second um I think it was Kim Kim here's here's essentially the response so in the protocol um member it's it's the string this is an old old name um we're we're in the midst of like normalizing everything uh and then the data uh contains the VB token. Geun-Hyung Kim: Okay thank you I screen captured so I can I can start playing with it thanks. Tim_Cappalli: Um okay and I promise I will come back to issue once it's in here um and I'll talk about in a second um. Tim_Cappalli: Check 10 minutes yeah got. Harrison_Tang: Sorry Tim there's 1 more question uh from Zachary is uh it's a how much information is available to the device and Os in the various step of the request response. Tim_Cappalli: Uh so the browser passes the raw request that's passed into the digital credentials API to the matter um and the output of the the wallet right the encrypted response and the request is sent back right so that's those are the only 2 inputs and outputs. Harrison_Tang: Cool hopefully that this answers your question. Harrison_Tang: Alright thanks uh please proceed thanks. Tim_Cappalli: Okay cool I'm gonna run a little quicker through this because we only have about 10 minutes but just kind of where we're at the most exciting that the most important thing from the slide is um we are hoping to migrate this work to the Federate identity working group uh in April um when we have a face-to-face right obviously the both groups need to agree that that's the right uh time and and agree that it's a good idea but we're fairly optimistic that that will happen which is great um because we've been in the ycg for a long time um and we hope to get a first public working draft out by June um which I think would make a lot of people around the world very happy to to see some more formality around this so long long way long way from uh the phyto wallet task force which I think some of you were involved in in 2021 um but we're we're finally there. <sam_goto> we call it a devtrial <aaron> may be interesting to think about what a malicious matcher could do <bumblefudge> ^^^^^ Tim_Cappalli: Current major work items so here you go Demetri um so the first 1 is defining issuance um so Google does have a um I guess it's beyond a prototype at this point um but issuance working and like I said I can send a video I'll find a way to share it um that Lee showed uh last week in the at a payments event um that that shows issuance uh and again that uses today open ID for VCI but you know Dev trial thank you so um but um you know other protocols could be added to the registry um we are also working on uh defining how to actually get into the registry right so there needs to be some agreed upon rules in the spec that says you know here's the minimum security bar for a protocol that's going to be added to the registry Etc that's 1 example. <sam_goto> yeah, that comes up a lot. it is safer to do on android because there is the play store policies, but harder on the open web. <dmitri_zagidulin> I think the matcher VM is very tightly sandboxed <sam_goto> yeah, information doesn't escape in or out, but it can still lie Tim_Cappalli: Um and as I mentioned uh the migration to the Federate identity working group um that has a little bit of process behind it right we need to come up with a list of um blocking issues um issue we we want to get issuance in there for example before we move it um and that is a um that PR is actually in in Flight uh and is undergoing feedback already um so we're pretty pretty confident that will happen so those are the 3 Big Work items that you know day-to-day working on um async and in the call. <sam_goto> e.g. say and intercept that it has a mobile drivers license Tim_Cappalli: And before I do this slide because this this could uh turn into a big discussion um did that enter your uh your issuance question Demetri. Dmitri Zagidulin: Side uh it does but broadly speaking is is the idea that the OS pops up a an app selection diagram or not diagram uh dialogue. Tim_Cappalli: Yeah so yeah so instead of instead of a credential picker it'll be like a a wallet picker yep. Dmitri Zagidulin: And there's corresponding matcher uh affordances that says I'm ready to accept such and such credential. Tim_Cappalli: I believe that is the same pattern why. Tim_Cappalli: All right um so the last thing um and then we'll I guess we'll probably end up with 5 minutes for questions you know the question keeps coming up right the DC API versus fcm like they're they're both hang off cred man um you know digital verifiable digital credentials are arguably just a new way to do Federation uh and fed CM kind of started its life as as working with Federation protocols um so like what are the differences right and before we say that maybe I'll start with the commonality right they're both protocol agnostic right fed CM doesn't say You must use open ID connect ID tokens it happens to be that's what most people are using it for but there's nothing in the spec that says You must um same thing with the DC API it's it's protocol agnostic and uh the and also credential agnostic even you know 1 layer removed from credential agnostic um they're both Federation Centric right again like they're they're they're they're they're largely um. Tim_Cappalli: coming to. Tim_Cappalli: At the end of the. Tim_Cappalli: Flow right you're passing claims from um an issuer whether that's in real time or or at a future point right you're you're you're taking a a set of claims that someone uh said about you or gave to you and passing them off to another party um both of them avoid redirecting custom schemes right so redirects are very heavily used and the Federation world with things like open ID connect um with fzm um you don't need redirects um and with the DC API there's no Redux in the first place. Tim_Cappalli: uh and. Tim_Cappalli: I mentioned they. Tim_Cappalli: Whole thing off credit man so a lot lot in common um 1 of the big differences right is fed CM operates in what I would say same context same device right so fed CM operates in a browser context um that context is not necessarily shared outside of the browser um right so so if you were going between 2 browers you wouldn't necessarily be able to take a response uh given through browser 1 to browser 2 Laurene um in the DC API right you are since the browser is not directly um the holder of this assertion right you can pass it to whoever whoever you choose as the user right so it operates in a cross context uh on the FED Zam side for device wise write that 1 contextos. Tim_Cappalli: And in terms of protocols that are typically used again they're both protocol agnostic but the ones that have been seen in kind of these early few years of usage typically fed cm is using open ID connect um and typically the DC API is using open ID for BP for presentation. Tim_Cappalli: And God damn say say say some stuff. <aaron> feels like Android Intents for the DOM <aaron> DC and FED CM are just diffrent Intents and there could be more Harrison_Tang: Money in it. Manu Sporny: Yeah and and and thanks for that same I think the perennial question is um uh are these circles going to end up basically overlapping completely from a use case perspective right I mean I think there's been argument that like oh they're different and and you know all that kind of stuff but if we look at convergence over the long term and I'm talking like 10 to 20 years versus like the next 3 um developers are probably not going to want to support both it's just you know complex and things like that and I think it's been put forward that the DC API could potentially uh address all of the uh use cases that the FED CM you know API uh would would um cover have have we seen I I know that this kind of is a debate that's been raging and and frankly I don't know if we really need to have a debate over it because I think there's it's either going to happen or it's not right um and they're kind of natural pressures on on developers to to to. <harrison_tang> I think in DC, the holder/wallet is in control. In the current FedCM, IDP is in control. That's another big difference. Manu Sporny: Right list code and and converge if it's if it's possible so have there been any breakthroughs lately on that question or is it still kind of a debate that's probably never ending and it's going to keep going on for years. <kim_duffy> Curious to hear about plans to address Brave objections before we run out of time Tim_Cappalli: Yeah I mean but 1 thing I would add right um. Geun-Hyung Kim: https://lists.w3.org/Archives/Public/public-review-comments/2024Sep/0017.html <bumblefudge> ^^ Tim_Cappalli: Fed ZM is also has some really awesome use cases for Workforce and Enterprise where a lot of the Privacy preserving properties of of vdcs are actually not desired um right telling the IDP where you sign in is actually a feature not a bug um so that's an example of somewhere where I I I don't think I don't think you're going to be signing in to work resources on a regular basis with a VDC right it doesn't ergonomically doesn't make a lot of sense for users um and also you lose a lot of the visibility which is there by Design um so that's another area I think they will split off. Harrison_Tang: All right so 1 1 last question this is from Ken uh she's curious to hear about the addressing Brave objections. Harrison_Tang: I think that that objection has been overturned right so. Tim_Cappalli: It is I I mean I'm I would recommend just reading the. <dmitri_zagidulin> what WAS the objction? Tim_Cappalli: The statement from the group uh I'm not not sure I have a lot to add there personally. Dmitri Zagidulin: https://lists.w3.org/Archives/Public/public-review-comments/2024Sep/0017.html [scribe assist by Geun-Hyung Kim] <dmitri_zagidulin> @Kim - thanks! Wendy_Seltzer_(she/her): Uh just get as the 1 of the working group co-chairs um echoing Tim's statement there the the council was asked to to review the the formal objection and uh overturned it um but said that the the group should continue to uh consider the questions raised and so as the the API comes forward uh in the working group um we will continue to to address privacy uh and other concerns raised by uh any participant. Geun-Hyung Kim: Thank you yeah just want to make sure that the objections. Geun-Hyung Kim: Yeah I just want to make sure that those remain top of mind and that the group does intend to follow up on that. <dmitri_zagidulin> thanks Tim and Sam!!! Harrison_Tang: Great uh I think we're at time and uh big thanks Tim and Sam for jumping on and actually need this discussion this is a great great session so and great works so thank you. Tim_Cappalli: Thank you what's the best way for me to get you this deck just email. Harrison_Tang: Yeah just email me and or you can just reply to the public threat or I can do it for you yeah thanks. <zacharias_törnblom_third_attempt> and the recording can be found where? Harrison_Tang: Right this concludes this week's ccg meeting thanks a lot. <harrison_tang> I will email out the recording to the public CCG list in a day or two
Received on Monday, 10 March 2025 17:01:56 UTC