8G/ Webauthn, WebOTP, FedCM, Password Managers - Relationships?

Webauthn, WebOTP, FedCM, Password managers - what is their relationship(s)?

Session Convener: Heather Flanagan, Tim Cappalli

Notes-taker(s): Heather Flanagan

Tags / links to resources / technology discussed, related to this session:

ICloud keysync security white paper - useful reading To continue the conversation, the W3C Webauthn working group allows anyone to post in the repository.

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Webauthn - most people in the room are familiar with this

WebOTP - one time passwords that will let phone numbers and email addresses be verified by exposing web platform APIs. Currently over SMS but there is a proposal for email. Launched and in production.

FedCM - a browser API being developed by google to allow federation (OIDC, SAML) to continue to work as browsers overall move towards more privacy protection. It does this by preventing tracking from impersonating themselves by using the API. In Chrome Origin Trials on Android; will be on desktop in next

What do password managers have to do with this? They also help manage credentials.

We have a spectrum of credentials and accounts

Assertion with claims Assertions about authZ

Credential <——————(what gets returned)—————->Account

PW manager —————-> FedCM

OTP —————-> OIDC

Webauthn (1:1) —————-> SAML

SSI

With Webauthn, they wanted to make the credential usable across platforms and devices. Account recovery and cross-ecosystem authentication should be covered by FIDO. They have to be presented across platforms, but not moved across platforms. Portability of keys is not in scope.

WebOTP is a way to bring it full circle; it’s not an authentication. It’s form-fill, and closer to password managers.

NASCAR wallet / IdP selection? FedCM will partially address this (?) Idea to take the FIDO stack, run the browser side in parallel to invoke a wallet and allow the CTAP to present it from other devices.

Webauthn lives in W3C with a dotted line to FIDO CTAP (browser to client)

If Webauthn and pass keys become broadly used, does that replace the NASCAR problem entirely? Webauthn are not identity. Identity attributes need to be verified in a way that Webauthn couldn’t handle.

You can ask for FedCM and Webauthn at the same time.

Worth noting that the “credential” in the name Federated Credential Management is about the idea of a browser credential, which is not the same as an identity credential.

Regarding the idea that Webauthn replacing federation - even with first party relying parties, you’re still going to be using federation between those entities. You want people to log into Google, not YouTube.

When pass keys are awesome, will we still expect to see “sign in with Google, Facebook, etc”? Yes, you’re just pushing to a different part.

As a student that gets an email that says “come get your credential” and then the user has to pick what wallet to store it in - how will that work? The OS will need to understand the basic PE response and respond with the right wallet. Can this be handled at the browser level instead? Maybe. It could be both, but for consistency, probably want it at the OS level so that apps and browsers behave the same.

Why is it compelling for RPs to get their claims in new ways rather than in ways they’ve already implemented? They’re getting claims from multiple sources at once and not the same place at once. This is a completely new mechanism; if we added something like a wallet picker to FedCM, RPs could use existing mechanisms. It needs to be compelling to RP developers. It will also allow RPs to use “expensive” credentials (like driver licenses) that they wouldn’t otherwise be able to use. The existing claims are coming as SAML assertions, id tokens, and they contain claims that the IdP is asserting. We’re talking about new kinds of claims offered by new sources; that distinction matters because we don’t have that ecosystem today. If RPs want new, verified sets of claims, they will write code. The IdP won’t have to hold all the info.

What is the compliance statement? What is the risk? What kind of regulations will impact this?

Why wouldn’t we reuse OIDC to transport verifiable credentials? Because of the NASCAR problems.

Credential Handler API (CHAPI) is in browserland, existing as a polyfill (JavaScript code that mimics browser UI), exposes 3 API calls - register a wallet and get a credential and store a credential. Would be another thing to explore.

The term “wallet” is getting overloaded. You shouldn’t have to be a wallet but you can be an app that can serve wallet content (e.g., Avis app holds insurance info and acts as a wallet for this particular piece of info)