Meeting minutes
TPAC recap
Ian: What feedback do people have from TPAC?
NickTR: I left TPAC the most energized I've been for several years. There's a lot of really exciting progress around authentication. Digital credentials work is interesting. What I was excited to see real interest and opportunity beyond cards in PIX and UPI and other payment use cases.
… we want architecture to support those and so it was heartening.
… and the WPSIG meeting aligned well with the WPWG work
Ian: I plan to write a TPAC summary (hopefully done this week). The big topics for the summary will be SPC progress, digital credentials (for payments), and other topics of interest.
Henna: What's the best way to stay close to the digital credentials work?
Ian: I took an action to reach out to Tim Cappalli and others to figure out where the conversations are happening and how to get involved. One idea is for the WPSIG to periodically host conversations. Stay tuned.
NickTR: If you have feedback on TPAC / suggestions let us know!
Next steps browser-based key in SPC
Ian: With initial input from Visa and based on discussion at TPAC and subsequently, I will display a list of "requirements related to a browser-bound key (BBK)". My plan is to create a document in the WPWG repo with these requirements after closing the loop with Visa on the topic of attestation.
Henna: Still working through that.
<nicktr> I found this FIDO technical note on attestation very helpful - I don't know if FIDO has changed its position but at least originally, attestation was about describing the model/class of authenticator, not the individual device
Ian: I was wondering whether the attestation might be bound to a group of devices (for privacy reasons) and say "This is a key signed by a device model from me"
NickTR: That FIDO article is related to that point; note that it was written prior to growth of platform authenticators.
Henna: In general with passkeys now we don't have any attestation. We have expressed concerns about that. That's why attestation around BBK came up.
… there's definitely need for attestation on BBK and need to figure out whether that's possible. We still wonder whether that is sufficient, or what else is needed.
… there would be a certificate telling the RP this is a trustworthy device.
… question is whether that's even possible as a starting point.
Rouslan: Not all authenticators support attestation.
Ian: Could we walk through how this might work from a technology perspective?
smcgruer_[EST]: Suppose we are talking about an Android device. At manufacturing time, a certificate is embedded in the device that can be chained to a wider scope certificate. This establishes a chain of trust, ultimately back to manufacturer. So at authentication time, the device can sign something with the certificate, and the RP can fetch the certificate from Google One question is "what are you actually trying to prove." through such an attestation? It's hard to prove that a device is definitely trustworthy. What if there is malware on the device?? The TPM might be intact but malware may undermine other expectations. So it's important to understand the security requirements. Not all devices expose TPM attestations (to the best of my knowledge)
Ian: Anything needed around storage of the BBK?
Doug: This is an important topic. It relates to how the BBK is generated. Back to Stephen's comment and malware...we'd like to get a better understanding of how the BBK is stored. Could it be stored outside of the JS environment?
… can it be isolated from any JS layer and stored outside of that "level of the browser"?
rouslan: From a spec perspective, that's an implementation detail. But from a requirements perspective, yes it would be isolated.
rouslan: There is browser isolation and the guarantees depend on the operating system.
Henna: Are you saying that the BBK generation process would be subject to how the browser works with the OS, and that won't be standardized?
rouslan: The isolation part may be browser-specific. Depends on the OS.
Next meeting
<Ian> Next meeting: 24 October