- From: Adrian Gropper <agropper@healthurl.com>
- Date: Sat, 14 Apr 2018 15:39:55 -0400
- To: Adam Powers <adam@fidoalliance.org>
- Cc: Mark Chipman <markchipman@gmail.com>, Credentials CG <public-credentials@w3.org>, Steven Rowat <steven_rowat@sunshine.net>
- Message-ID: <CANYRo8gaTjV1p-vn1jDBDQyoqi3wLO5DFPFQ3UHO-6JC=Y2=0A@mail.gmail.com>
Adam, thanks for confirming my memory about FIDO. All, What's confusing me is the statement: *"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."* It seems to me that FIDO and DID are solving the same problem the same way using different protocols. If the DID protocols were compatible with FIDO, the relying parties would not have a reason to care what the authenticator was (other than the metadata itself implying a security level) and both FIDO and DID would gain adoption. 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. Do I get it? Adrian On Sat, Apr 14, 2018 at 2:24 PM, Adam Powers <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) > 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> > 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 >> > 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 >>>> >>>> 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>) 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> >>>>> 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>> 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>) >>>>> >>>>> 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> >>>>>> >>>>>> 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/> >>>>>> >>>>>> 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/ > > -- 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 Saturday, 14 April 2018 19:40:25 UTC