- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Sat, 14 Apr 2018 17:36:45 -0700
- To: Adrian Gropper <agropper@healthurl.com>, Adam Powers <adam@fidoalliance.org>
- Cc: Mark Chipman <markchipman@gmail.com>, Credentials CG <public-credentials@w3.org>, Dave Longley <dlongley@digitalbazaar.com>
To, @dlongley, Thank you for the detailed explanation of pairwise DIDs and privacy. That clarified several things that I was fuzzy on. @adam, you said: > ...(For example, Facebook may have > some value in users centralizing all their information in a > Facebook account). ...<snip>...DID > offers some value that persuade some away from centralization I think this example nails the nub of it, when looking at what those DID values might be. My understanding is that DIDs have been developed because they offer users the options of privacy, pseudo-anonymity, and selective release of their own data (including data portability). Whereas Facebook is opposed to people having all three. It offers a service in which it prohibits anonymity — presumably, not to mince words, because it needs real people that it can track — and by its own architecture subverts privacy and selective release of data by confusion and obfuscation. It operates by having as much data a possible about a real user, which it sells by means of charging advertisers. And so, yes, in DIDs there will be "some value that persuade some away from" this -- which is, that all three of these things -- privacy, pseudo-anonymity, selective release of data -- will become explicit choices for the user. Whether this can be technically achieved, as Dave Longley was addressing in the pairwise DID post, is still unknown. But to me it's clear that Facebook's business model could be seriously undermined if a large number of people took advantage of it, and so it's logical to presume, or at least plan for, the possibility that they may not want DIDs to exist at all; and the same for Google, and any advertising, data-collecting-based service. @adrian > The vendors in the FIDO alliance that are in the > federated ID business might not like that because DID would provide > additional functionality to the subjects and therefore reduce the > utility of federated identity providers that just use FIDO as a > pure security (rather than privacy) enhancement. If I understand you, yes; I believe this is another way of saying what I said above in the Facebook example; ie, if you mean that Facebook "might not like" the fact that DIDs give people more control over their privacy. Which I believe is a reasonable possibility. Steven Rowat > Do I get it? > > Adrian > > On Sat, Apr 14, 2018 at 2:24 PM, Adam Powers <adam@fidoalliance.org > <mailto:adam@fidoalliance.org>> wrote: > > Adrian, I think what you are talking about is the "attestation > certificate". Each time a user registers with a new service, an > authenticator creates a new key pair for that service. The new > public key is signed by an attestation certificate that is baked > into a specific model of authenticator (Samsung phone, Huawei > phone, YubiKey, etc.) which provides a few features: > > 1. Root of trust during registration (which tends not to be as > critical as you might suspect) 2. Proof of which model of > authenticator is being used 3. Ability to access metadata bout the > device (which modality of biometric is being used; whether private > keys are stored in SE / TEE / TPM / software; what types of > certification the device has received; etc.) > > The rule is that the attestation certificate is per model (e.g. - > Samsung Galaxy S8), and not per device (e.g. - Adam's Samsung > Galaxy S8) to prevent the attestation certificate from becoming a > correlation handle. > > I think this is different from Mark and Steven's point that perhaps > some services may not value DID and really want to lock people in > to using their specific accounts. (For example, Facebook may have > some value in users centralizing all their information in a > Facebook account). I don't know: if that's true; which entities > would subscribe to that way of thinking; if there are different > perspectives and / or use cases across different entities; if DID > offers some value that persuade some away from centralization; etc. > The best I can offer is that we should solve the few technical > problems we've identified, and then approach the conversation of > adoption with an open mind and spirit of collaboration. > > > On April 14, 2018 at 8:59:21 AM, Adrian Gropper > (agropper@healthurl.com <mailto:agropper@healthurl.com>) wrote: > >> I’ve not kept up with FIDO. Last I recall, the centralization was >> in the form of a certificate issued by the vendor to the secure >> elment that itself had no serial number that would identify the >> specific SE to a relying party. This, in and of itself, does not >> seem to enable lock-in or correlation. It seems similar to Apple >> saying their SE does not leak serial numbers if I recall that >> correctly. >> >> What am I missing? >> >> Adrian >> >> On Sat, Apr 14, 2018 at 9:10 AM Mark Chipman >> <markchipman@gmail.com <mailto:markchipman@gmail.com>> wrote: >> >> Re: " Interesting. This "can't be used across multiple sites", as >> I understand it, was a major reason why Verifiable Credentials >> and then DID have been developed -- to give the user/owner the >> control over their own identity data, so they can move from site >> to site and their data isn't locked in by a single vendor >> system. >> >> >> So, this is still a major problem; and one which, perhaps, many >> vendors in the FIDO alliance would rather wasn't solved? Because >> I think it's fair to say that at least some of the large >> corporations involved have a business model that depends on >> having that data all to themselves." >> >> I couldn't agree more with Steven's point!... especially this: " >> perhaps, many vendors in the FIDO alliance would rather wasn't >> solved?" We need to avoid vendor lock-in. >> >> - Mark Chipman >> >> On Fri, Apr 13, 2018 at 10:10 AM, Steven Rowat >> <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net>> >> wrote: >> >> On 2018-04-12 11:17 PM, Adam Powers wrote: >> >> Great point, here are the links from my presentation (there were >> a couple other presentations as well): >> https://drive.google.com/drive/folders/1LyYp_SZpqboIPfUa1lo9zKtNv9SIv-5I?usp=sharing >> >> <https://drive.google.com/drive/folders/1LyYp_SZpqboIPfUa1lo9zKtNv9SIv-5I?usp=sharing> >> >> I think the only real problem we encountered was that (by design) >> WebAuthn uses "origin" to bind authentication to a specific >> service. It's a solvable problem, it will just take some >> conversation to figure out the pros and cons of some of the >> solutions that were mentioned. At the very least, it's >> implementable / demo-able now but the same DID can't be used >> across multiple sites until the origin issue gets solved. >> >> >> Interesting. This "can't be used across multiple sites", as I >> understand it, was a major reason why Verifiable Credentials and >> then DID have been developed -- to give the user/owner the >> control over their own identity data, so they can move from site >> to site and their data isn't locked in by a single vendor >> system. >> >> So, this is still a major problem; and one which, perhaps, many >> vendors in the FIDO alliance would rather wasn't solved? Because >> I think it's fair to say that at least some of the large >> corporations involved have a business model that depends on >> having that data all to themselves. >> >> And it seems, based on the presentation linked above, that this >> is relatively easy to solve, technically; or if not easy, at >> least doable. >> >> Yet will it be done? Because it doesn't seem easy to predict how >> it will all play out politically. >> >> IMO that may depend on there being sufficient demand for DID that >> the WebAuthn can't ignore it, even if some of those supporting >> WebAuthn would actually rather DID just failed. ;-) >> >> >> Steven Rowat >> >> >> >> On April 12, 2018 at 10:19:06 AM, Andrew Hughes >> (andrewhughes3000@gmail.com <mailto:andrewhughes3000@gmail.com> >> <mailto:andrewhughes3000@gmail.com >> <mailto:andrewhughes3000@gmail.com>>) wrote: >> >> At the Internet Identity Workshop (IIW) last week in Mountain >> View, there were some sessions discussing exactly this topic - >> how should WebAuthn and Verifiable Credentials and Credentials >> Community Group work together - leaders from each of the efforts >> were in attendance. >> >> andrew. >> >> *Andrew Hughes *CISM CISSP *In Turn Information Management >> Consulting* >> >> o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, >> BC V8P 2H8 >> <https://maps.google.com/?q=1249+Palmer+Road,%C2%A0Victoria,+BC+V8P+2H8&entry=gmail&source=g> >> >> AndrewHughes3000@gmail.com >> <mailto:AndrewHughes3000@gmail.com> >> <mailto:AndrewHughes3000@gmail.com >> <mailto:AndrewHughes3000@gmail.com>> >> ca.linkedin.com/pub/andrew-hughes/a/58/682/ >> <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/> >> <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/ >> <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/>> *Identity >> Management | IT Governance | Information Security * >> >> >> On Thu, Apr 12, 2018 at 10:08 AM, Adam Powers >> <adam@fidoalliance.org <mailto:adam@fidoalliance.org> >> <mailto:adam@fidoalliance.org <mailto:adam@fidoalliance.org>>> >> wrote: >> >> The quickest summary: WebAuthn is a way of generating public key >> pairs, storing a public key on a server and the private key in an >> "authenticator", and later using that key pair for authentication >> to a service. >> >> Insofar as DID is storing a public key in a DID document, that >> public key can be generated by WebAuthn and stored by DID. The >> most obvious overlap between DID and WebAuthn would be using >> WebAuthn as the mechanism for DIDAuth -- although there is still >> some work that needs to happen there to define and align the >> specs. In my perspective, they should be complimentary and not >> competitive. >> >> I hope that helps. >> >> Adam Powers, Technical Director, FIDO Alliance >> >> >> >> On April 12, 2018 at 9:24:03 AM, Steven Rowat >> (steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net> >> <mailto:steven_rowat@sunshine.net >> <mailto:steven_rowat@sunshine.net>>) >> >> wrote: >> >> Greetings, >> >> The Guardian yesterday had a story of what appears to be a major >> announcement about how WebAuthn will replace passwords: >> >> https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method >> >> <https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method> >> >> <https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method >> >> <https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method>> >> >> This included a quote showing that this is a W3C project: >> >> “WebAuthn will change the way that people access the Web,” said >> Jeff Jaffe, chief executive of the World Wide Web Consortium >> (W3C), the body that controls web standards." >> >> And after looking at the recent API spec itself, I see that it's >> a FIDO project, and so supported by Google, Microsoft, Paypal, >> and also Mozilla: >> >> http://www.w3.org/TR/2018/CR-webauthn-20180320/ >> <http://www.w3.org/TR/2018/CR-webauthn-20180320/> >> >> <http://www.w3.org/TR/2018/CR-webauthn-20180320/ >> <http://www.w3.org/TR/2018/CR-webauthn-20180320/>> >> >> My Question: >> >> Is there any expected or known relationship between WebAuthn and >> the use of DIDs? ie., Can WebAuthn be used with DIDs? Will the >> uptake of WebAuthn preclude or inhibit the use of DIDs? >> >> ie., Are DID Docs and WebAuthn in competition, or are they >> complementary? >> >> Steven >> >> >> >> >> >> >> >> >> >> >> -- - Mark >> >> -- >> >> Adrian Gropper MD >> >> PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for >> the right to control personal health data. DONATE: >> https://patientprivacyrights.org/donate-3/ >> <https://patientprivacyrights.org/donate-3/> > > > > > -- > > Adrian Gropper MD > > PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the > right to control personal health data. DONATE: > https://patientprivacyrights.org/donate-3/
Received on Sunday, 15 April 2018 00:37:15 UTC