IdP Blindness: User Info VCs #677
Comments
samuelgoto
changed the title
samuelgoto
changed the title
|
Just a small update here: we intend to prototype this and see where it might take us. |
Another update here: I just finished merging a prototype behind a flag in chrome canaries (here are the CLs if you want to reverse engineer) and kicked off a devtrial. Here are some instructions on how you can give this a try in Chrome:
You should get something like the following without telling the issuer who the verifier is: Screen.Recording.2024-12-20.at.13.57.23.mov |
samuelgoto
changed the title
Delegation-oriented FedCMThis is an early proposal to unbundle issuance from presentation with the verifier-holder-issuer model to address the IdP tracking problem of social login by making the browser a holder. In this explainer we'll go over:
Background and motivation
Early on, we outlined a few important problems we wanted to address in federation: first and foremost The Classification Problem (the fact that browsers couldn’t tell the difference between federation and tracking), and then The RP Tracking Problem (the release of global identifiers, such as emails) and The IdP Tracking problem (the bundling of presentation with issuance). It wasn’t clear where we should start, so we looked at three different variations that had different trade-offs. We called them the Mediation-oriented model, the Permission-oriented model and the Delegation-oriented model. We learned quickly that it was key to start from the first two variations, because they were the most backwards compatible. So, the Mediation-oriented model and the Permission-oriented model materialized - after many iterations - as FedCM’s mediated account chooser and the Storage Access API (by itself, or even in conjunction with FedCM). A series of heuristics were also put in place, which covers a lot of ground too, again optimizing for backwards compatibility with the Web. The Mediation-oriented API, notably, was a great starting point because it (a) solved The Classification Problem, (b) allowed solving the The RP Tracking Problem (with directed identifiers) and, importantly, (c) didn’t require any user experience or behavioral change (as opposed to the Permission-oriented variation), allowing it to be deployed at large scales. So, while the first two variations optimized for backwards compatibility (and, between them, a trade-off between performance, extensibility and ergonomics), they had an inherent privacy design weakness: The IdP Tracking problem. That brings us to the Delegation-oriented model, which has great privacy properties in keeping IdPs blind, but requires us to redeploy a much larger part of the ecosystem: tens of thousands of relying parties. We are not sure yet whether the delegation-oriented model is actually within reach at this point, but a few stars aligned recently. For one, the introduction of the issuer-holder-verifier architecture, together with the deployment of new token types like SD-JWT+KB, made the unbundling of issuance from presentation a lot more accessible. Zero knowledge proofs have also advanced much since we started, giving us some hope that we could solve both the RP Tracking Problem and the IdP Tracking Problem at the same time. Asides from the new externalities introduced, the development of the Mediation-oriented variation allowed us to stand on top of a much higher foundation compared to where we started from. The last 2-3 years of production experience of FedCM across thousands of websites and millions of users required us to design a series of features and extensions (e.g. handling logged-out users, switching accounts, extensibility, handling multiple idps at a time, a registration mechanism, the pull and push model, and a series of control knobs) that we can build the delegation-oriented variation from. This is still early and ambiguous, so it is very possible it won’t go anywhere. Nonetheless, it is probably the closest that we have ever been, and close enough that it feels worth taking a shot. The explainer linked above has some notes of the overall idea that we’d like to start from. ProposalHere is an end to end demo to give a sense of what this could look like. Instructions on how to use this here. 397879327-155e43fa-7644-485f-b7a0-0e8c699c40a4.movArchitecturally, here is more or less what we are proposing. We'll break down this diagram into the following sections:
sequenceDiagram
participant website
participant browser
participant issuer
website->>browser: Give me a signed "sub" and "name", given "nonce"
browser<<->>issuer: Vanilla FedCM, creates an account chooser
browser->>browser: User selects account, choosing to Sign-in
browser->>browser: Generate ephemeral key pair
browser->>issuer: Issue me an SD-JWT bound to public key
issuer->>browser: Here
browser->>browser: Selectively disclose "sub" and "name"
browser->>browser: Bind "aud" and "nonce" with private key
browser->>browser: Throw away private key
browser->>website: Here is a SD-JWT-KB
website->>website: Checks issuer's signature
website->>website: Checks "aud" and "nonce"
website->>website: Accepts "sub" and "name"
The Verifier APIIn the three party model, the Identity Provider unbundles issuance from presentation, and delegates the latter to the browser. When it chooses to break itself into two parts, we’ll call the first an Issuer (rather than an Identity Provider) that delegates presentation to the second, a Holder (the browser), a now three party model (verifier-holder-issuer) rather than the two party model (rp-idp). The three party model is compelling because it solves the IdP Tracking Problem: the ability to login to websites without telling the Identity Provider. The way this is constructed is by having the browser operate as a holder. The holder has to accept presentation requests from verifiers, accept provisioning requests from issuers and ask users permission for presentation. To do so, it has to support a specific token format (e.g. SD-JWTs, MDocs and BBS) as well as an ontology (e.g. OIDC’s standard claims, HTML5’s autocomplete as well as FedCM’s profiles), so that it knows how to compute the selective disclosure as well as how to ask the user’s for their permission. For the sake of simplicity, let me start by anchoring on SD-JWTs and OIDC’s standard claims, because that’s what’s most comparable to OIDC’s Id Tokens (which uses JWT’s + standard claims, making the only delta the introduction of SD - selective disclosures - and KB to JWTs). The verifier is given a new attribute, called const {token} = await navigator.credentials.get({
identity: {
mode: "active",
providers: [{
format: "vc+sd-jwt",
fields: ["email"], // I only need the user's email
nonce: "5678",
configURL: "https://idp.example/config.json",
}]
}
});When that format is used and supported by the issuer (see below how the issuer opts-in), the verifier gets what’s called an This is a three part token: first, a set of SD (selective disclosures), an Issuer-Signed JWT and a KB (proof of possession key binding). const {jwt, discloures, kb} = parseSdJwtKb(token);First, the verifier gets an Issuer-signed JWT like it normally would for idtokens: // Jwt Header
{
// Tells the verifier how to verify the issuer's signature
"alg" "ES256",
// Tells the verifier where to find the issuer's public key
"jku": "https://issuer.example/jku.json"
// Tells the verifier that this is an SD-JWT
"typ": "sd-jwt",
}
// Jwt Payload
{
// Typical JWT attributes:
"iss": "https://issuer.example",
// The time this was issued
"iat": 2342342,
// The time when this token expires
"exp": 234342342,
// Notably, there are two key importants things that are deliberately
// removed:
//
// - The "aud" and "nonce" are missing. See KB below.
// - The "firstName", "email", "picture" standard claims. See discloures below.
// Instead, two other attributes do that job now:
// First, the holder's public key, who the issuer delegates "aud" and "nonce".
"cnf": {
"crv": "P-256",
"kty": "EC",
"x": "h29tWfkCJ73nJbP51C4SotdI0CuttfQS3Svt0se6gFU",
"y": "mBavlbiJLFhGsuIJRz7wYLiW15gpiWEDLjE1gfVh_7k"
},
// Second, selective disclosures digests, without the original values revealed.
// Also, delegated to the holder to disclose.
"_sd": [
"6phoD5MBMETkuf5BYia7JD01dubqJSwGuz-o_9M206E",
"8jxEyPj9mMqJ6DQW6xiQrkyjryn77Sbuc2N44ScEGlE",
"D45wfxz18dwlcKeuvFppyAPl4rc-WE2Fn3f5fg3W1Ow"
],
"_sd_alg": "SHA-256"
}
// Jwt Signature
"METkuf5BYi .... D5MBa7JD01du"But then, in addition to the Issuer-signed JWT, the verifier gets two more things. First, a list of attributes that the user chose to disclose: ["6403945e2c0a34a4", "firstName", "Alice"]
["06cbb1a51984f444", "lastName", "Doe"]You’ll probably notice that there are three parts here to each disclosure: a randomly generated salt (e.g. The salt is used to create a random value that can be used to compute a value such that it can be included in the const digest = SHA256(disclosure),
// Checks if the digest is included in the Issuer-signed JWT
if (!token.jwt._sd.includes(digest)) {
throw Error("Disclosure didn't match")
}The last bit that the verifier gets is what’s called the Key Binding token. The Key Binding token is used to prevent replay attacks: the verifier’s server has to be convinced that the token that it gets was addressed to them and is recent (e.g. matches a nonce). If the Key Binding token wasn’t provided or required by the verifier, a malicious verifier could use a SD-JWT to send it to another verifier to "replay it" (e.g. authenticate a user in another verifier when the user intended to authenticate into the specific verifier). To do that, the verifier gets the following KB JWT: // Key Binding Jwt Header
{
// Tells the verifier how to verify the signature
"alg": "ES256",
// Tells the verifier that this is a Key Binding JWT
"typ": "kb+jwt",
}
// Key Binding Jwt Payload
{
"aud": "https://verifier.example",
"nonce": "__a_verifier_provided_challenge__",
}
// Key Binding Jwt Signature
"D5MBa7JD01du .... METkuf5BYi"The The verifier also verifies that the signature matches the public key that was provided by the Issuer-signed JWT, so that it can’t be forged by anyone but the holder that the issuer trusted with this specific Issuer-signed JWT. The Issuer APIIn order to hand to the verifier what it needs, the browser coordinates with a cooperative issuer (as it normally would for baseline FedCM). As baseline FedCM, the browser carries on as it normally would, all the way into the disclosure UI, but before the browser hits the The The VC Issuance endpointTo avoid revealing to the IdP who the Rp is, we introduce an entirely new HTTP endpoint, say // IdP's Config File
{
// usual endpoints
"accounts_endpoint": "...",
"id_assertion_endpoint": "...",
// newly introduced vc_issuance_endpoint
"vc_issuance_endpoint": "...",
// newly introduced parameter: tells the browser that
// the vc_issuance_endpoint can return VC+SD-JWTs.
"formats": ["vc+sd-jwt"],
}With this information in the configURL from a cooperating IdP, when the browser arrives at the end of the flow, it notes that the For the
When the Here is an example of what that request looks like: You’ll note that nowhere in this request (headers or body) does the browser tell the issuer who the verifier is. Here is an example of what the end result might look like: eyJ0eXAiOiJzZCtqd3QiLCJhbGciOiJFUzI1NiJ9.eyJpZCI6IjEyMzQiLCJfc2QiOlsiNnBob0Q1TUJNRVRrdWY1QllpYTdKRDAxZHVicUpTd0d1ei1vXzlNMjA2RSIsIjhqeEV5UGo5bU1xSjZEUVc2eGlRcmt5anJ5bjc3U2J1YzJONDRTY0VHbEUiLCJENDV3Znh6MThkd2xjS2V1dkZwcHlBUGw0cmMtV0UyRm4zZjVmZzNXMU93Il0sIl9zZF9hbGciOiJTSEEtMjU2In0.T71daVMwfh9sd_9II_Wr67BHP4shOjhJ0vvqiC8tYrvTae8XirqnizIEpUoH7lEzKV5MaAlFZ8z2Tq5IRgXNfw~WyI2NDAzOTQ1ZTJjMGEzNGE0IiwiZmlyc3RuYW1lIiwiQWxpY2UiXQ~The Browser as a HolderWhen the browser gets this token, it goes over the Fields that were requested and only releases the disclosures that were (a) requested by the verifier and (b) acknowledged by the user. The browser, in possession of the SD-JWT, returns back to the Verifier the ["f3e080eb88b5f735","email","[email protected]"]Because of replay attacks, the browser also signs the KB token with the audience (for scope) and the nonce (for freshness) provided by the RP: {
"aud": "https://verifier.example",
"nonce": "5678",
}Here is an example of the response that the browser would send to the Verifier as a result of JS call: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~<KB-JWT>The browser throws away the public/private key that it used, rather than storing it. The website, in possession with this token, can cryptographically get a signed assertion from the IdP, while keeping the IdP blind to this entire transaction. Ta-da. The Push ModelAs far as the browser is concerned, I think we could make this work equally well with the push model. I think it is awkward for IdPs who are going to have to keep the content fresh (and increase the expiration times of the credentials), but it would be equivalent to the “classic three party model”. Here is what this could look like: // Stores it in the browser
await navigator.credentials.create({
identity: {
format: "vc+sd-jwt",
// uses the vc_issuance_endpoint defined in vc.json to
// issue a vc+sd-jwt ahead of a presentation request.
configURL:"https://issuer.example/vc.json",
}
});When RPs ask for the SD-JWT+KB, the browser can use the tokens that were issued ahead of time if they aren’t expired (and fetch a new one if they are). Relationship with related APIsRegistration, Passive mode, Lightweight and Multi-IdPThe intent here is that this proposal would seemingly integrate with other parts of FedCM, most importantly the Continuation API, IdP Registration API, Passive Mode and the Multi-IDP API. For example, if the Issuer wanted to get permission from the user dynamically with their own words (e.g. confirming trust in the holder) using HTML/CSS/JS they could use the Continuation API before IdentityProvider.resolve() with a token. Here is how I think all of these things come together cohesively: At the issuer: // At https://issuer.com
// Tells the browser that the user is logged-in, and uses the lightweight mode to cache the accounts endpoint
// See more information at: https://github.com/fedidcg/LightweightFedCM?tab=readme-ov-file#passive-mode-or-active-mode-without-fallback
navigator.login.setStatus("logged-in", {
accounts: [{
name: "Sam",
email: "[email protected]",
picture: "https://accounts.google.com/profile/goto/profile.jpg",
}]
});
// Asks the user to register itself as an Issuer
// More information at: https://github.com/w3c-fedid/idp-registration
IdentityCredential.register("https://issuer.com/vc.json");
// Issues a User Info VC to the browser's holder
// More information at: https://github.com/fedidcg/LightweightFedCM/issues/56#issuecomment-2542120956
navigator.credentials.create({
identity: {
configUrl: "https://issuer.com/vc.json",
}
});At the verifier: <html>
<script>
// More information at: https://github.com/w3c-fedid/FedCM/issues/694
const {token} = await navigator.credentials.get({
identity: {
mediation: "conditional",
providers: [{
type: "any", // accepts User Info VCs from anyone
format: "vc+sd-jwt", // takes SD-JWTs
fields: ["email"], // I just need the user's verified email address
}]
}
});
// Got an email address from the autofill!
// Creating a user account
const account = await fetch("/create-account.php", token);
// Gets a free passkey with a conditional create
// More information at: https://github.com/w3c-fedid/FedCM/issues/671
await navigator.credentials.create({
publicKey: {
user: account,
mediation: "conditional",
}
});
</script>
Welcome to my website!
Enter your email to create an account!
<form action="/create-account.php">
<!-- User can either enter email manually or get a verified one through FedCM -->
<input type="email" autocomplete="email fedcm">
<input type="submit">
</form>
</html>HOWTOCan I play with this? Yes, instructions here. Open QuestionsThis problem has a lot of design choices that we are still trying to understand. Here are a few open questions: Should we use ZKPs?I think the answer is likely "yes", but the more interesting question is "which" and "how". BBS+ comes to mind as a first thought, but we haven't explored this space enough to understand how to use it. We would appreciate guidance here. Should we support mDocs?I think the answer is also likely "yes". Besides zero knowledge proofs, we also have an intuition that we should support both SD-JWTs and mDocs. We started with SD-JWTs because there was better support in our codebase, but I think both could work equally well. If you know about any of these, we would love guidance if we are using them correctly too. Should we extend the Digital Credentials API?First, I think it is useful to acknowledge that this use case (Social login) could (and should) be helped by the Digital Credentials API too: we should encourage issuing User Info VCs to third party wallets and use them when available. However, I think if we relied only on that we'd either (a) have a much harder ecosystem activation / bootstrapping structure, (b) have to give up on the privacy properties of the three party model or (c) re-invent FedCM. By that I mean: in (a) if we keep the current DC structure, it will have to presuppose that User Info VCs were issued to third party wallets ahead of time with enough penetration before this verifiers can call this reliably making it harder to bootstrap the ecosystem, in (b) if we keep the current DC structure, because the DC API connects with wallets, issuers will have to be bundled with holders in the same app - if you assume that (a) is a non-starter, which defeats the privacy properties that we are looking for or in (c) if we change the current DC structure, we'd have to re-invent the FedCM endpoints in it. For a bit more context, architecturally, Chrome implements the Digital Credentials API as a "dumb pipe" to third party wallets where the browser plays the role of redirecting the request to third party wallets, without introspecting - by design - the request: originally, an alternative to custom schemes like Specifically, FedCM already knows (a) whether the user is logged in to a website or not and (b) how to login the user to a websites when the user is logged-out as well as (c) gather a list of accounts without revealing who the RP is. Digital Credentials simply routes requests to wallets, so, so far, the intuition is that we'd have to re-invent these FedCM (e.g. the algorithms above) inside of Digital Credentials if we wanted to extend it. From an ecosystem activation energy perspective, there are a lot of benefits of having the neutral user-agent act as a holder: issuers can register with it with a lot less friction than they would register with a third-party wallet. This isn't applicable to a lot of cases (e.g. government-issued credentials, issuers have one-off deals with wallets enforced by regulation), but we think is likely true for social login. So, so far, the intuition so far is that, while FedCM and the DC API operate in a similar design space, the former is a high-level API for Social login and the other is an extensible low-level API across more use cases (e.g. birth certificates, drivers licenses, passports, etc), so, co-existing much like high-level APIs (e.g. We are still learning from our prototype, so we'll keep an open mind about this architectural choice as we learn more about how they relate to one another. |
One problem that we identified early on that we still don't know how to solve is the IdP Tracking Problem: wouldn't it be great if we could login to websites without necessarily telling the Social login provider that we did?
Since we started developing FedCM, I think a lot has changed. For one, we got a lot more experience with zero knowledge proofs. For two, the three-party model got more mature too, with credential formats like SD-JWTs and ISO MDocs being deployed in systems like government-issued IDs. Importantly, we also developed a much stronger foundation with FedCM that we can stand on (e.g. we know how to construct a privacy preserving account chooser, log-in users that are logged-out, etc), making this problem a lot more tractable now than it was a few years ago.
I'm interested in ZKP formats most, but since MDocs and SD-JWTs might be bit easier to start from. I think zero-knowledge proof formats, such as BBS+, can increase the privacy properties here, and be supported in a similar architecture.
It is not yet clear to me what kinds of trade-offs this architecture will have, but I have an intuition that it will offer a very different set of properties compared to other alternatives. For example, this is clearly backwards incompatible with the existing server-side deployment, so will activate the ecosystem much more slowly than vanilla FedCM. But, on the other hand, I think that this is likely the most private cross-site identity system that we can build, because it involves the fewest entities possible, so will find its use in enough places.
The text was updated successfully, but these errors were encountered: