- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Fri, 13 Apr 2018 17:44:17 +0100
- To: public-credentials@w3.org
Hi Steven the IETF work on Token binding allows a token to be shared between two sites (e.g. issuer and verifier) via the user. This token can span multiple sessions, and therefore, if this token is bound into a verifiable credential that is issued specifically by the issuer for this verifier (whose identity is unknown to issuer), the user can present it to the verifier whenever he/she wants to, and the verifier can be assured that the VC was meant for itself, whilst the issuer does not know who the user is presenting the VC to, or when it is presented. This does not break the Web Auth model, as the user will use different public keys to talk to the issuer and the verifier. The only downside is that the user will need the VC to be duplicated for each verifier he/she visits, with each VC containing a different token value. But this is good privacy protection because it does not allow verifiers to collude and compare VCs (unless they contain a globally unique property such as email address, in which case privacy is lost). Regards David On 13/04/2018 17:10, Steven Rowat 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 >>> 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 >>>> >>>> >>>> >>>> >>>> >>> > >
Received on Friday, 13 April 2018 16:44:52 UTC