Re: Payments, Privacy, and Identity Credentials-based login (was: Re: U2F Demo)

On 30 May 2014 21:13, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 05/30/2014 10:59 AM, Herbert Snorrason wrote:
> > I've already asked about the mixnet elsewhere, so won't repeat the
> > question here...
>
> For those interested in how the Identity Credentials stuff works, this
> conversation may help clarify some of the more important bits. If you
> don't know anything about Identity Credentials and the Credential-based
> login proposal, reading this may help:
>
> http://manu.sporny.org/2014/credential-based-login/
>
> Some terminology for those that aren't familiar with these sorts of
> systems:
>
> IdP - Identity Provider (the website that stores and relays your
>       identity information)
> RP - Relying Party (the website that you're trying to login to).
> mixnet - A login masking service that prevents an IdP from tracking
>          which sites you're logging in to.
> UA - User Agent (a web browser, for example)
>
> Herbert Snorrason (Odin-), Dave Longley (dlongley), and myself (m4nu)
> had this conversation earlier today comparing/contrasting Persona,
> Identity Credentials, OpenID, and WebID:
>
> <Odin-> m4nu: I'm rather curious about this mixnet notion (re: Identity
> Credentials).
> <Odin-> I guess my main question is what purpose the mixnet serves. It's
> hiding the relying party from the IdP, correct?
> <m4nu>  Odin-: yep, exactly.
> <Odin-> Hrm.
> <m4nu>  It also digitally signs credentials going to the RP (to ensure
> that they're only valid for a few minutes, and that they can only be
> used w/ the target domain)
> <m4nu>  Odin-: Keep in mind that the mixnet is only for clients that
> don't have browser-support for this stuff. The second you have browser
> support, the mixnet goes away.
> <Odin-> Why can't you trust the shim to transmit the personally
> identifiable information?
> <Odin-> The only piece of information the RP really _needs_ from the IdP
> directly is their public key.
> <m4nu>  Odin-: did you mistype your first statement? "Why can't you trust"?
> <m4nu>  Are you asking "why can you trust?"
> <m4nu>  Odin-: There are a couple of things going on here, so let's break
> them down:
> <Odin-> Hmm. No, maybe this is just a terminology mismatch.
> <Odin-> 'mixnet' implies to me more than one hop.
> <m4nu>  The first thing you have to ensure is that the IdP can't find out
> where you're sending your credential information to (if it can, it can
> track you)
> <m4nu>  Odin-: Mixnet is bad terminology :)
> <Odin-> 'k. Then I get it.
> <m4nu>  Odin-: we just started using that word w/o much thought, so it
> probably doesn't mean what you think it means (we're abusing the term)
> <m4nu>  It's more like a masking service.
> <Odin-> The user agent sits, alone, in the middle of all communications
> between IdP and RP, then?
> <Odin-> (Apart from the "is the key right" question, obviously.)
> <m4nu>  Odin-: that's the ideal implementation of this technology, yes.
> <m4nu>  We need to bootstrap to that future
> <m4nu>  so, in the meantime, we're using a javascript + website shim
> (like Persona did) to provide the identity credential masking
> functionality.
> <Odin-> Once browsers provide crypto for JavaScript, there's hardly any
> reason to move away from a shim, even.
> <m4nu>  no, there is still a reason
> <m4nu>  (you don't trust the login masking website)
> <m4nu>  if it were compromised, you'd be boned (attackers could get your
> private keys)
> <m4nu>  So, you do want to get rid of the login masking website
> eventually and just route the request through the browser.
> <Odin-> Hm, fair enough. Although whether you actually trust the user
> agent is an open question, too...
> <m4nu>  but you can't do that in the beginning (because there will be no
> native browser support in the beginning)
> <m4nu>  Well, you have to trust /some/ piece of software
> <m4nu>  and the user agent has access to all the information anyway
> (nearly impossible to not have that happen w/o severe usability issues)
> <Odin-> Yes. And the user agent is the one with most scrutiny.
> <Odin-> But also the one the NSA is most likely to be interested in
> subverting. ;)
> <m4nu>  So, assumption #1 is: You trust your user agent.
> <m4nu>  Odin-: true.
> <m4nu>  which is why one would hope that an open source implementation
> would help prevent that from happening.
> <m4nu>  in any case, if it's not the UA, it's /some/ piece of technology.
> <m4nu>  some piece of software... you have to trust /some agent/.
> <Odin-> Well, actually, it always winds up back at the UA.
> <m4nu>  exactly
> <m4nu>  the choice's we're providing are: 1) the masking service runs on
> a trusted/audited website, like login-hub.com, or 2) the masking service
> runs in the UA (which is better)
> <m4nu>  We are only doing #1 right now because we need to bootstrap the
> system and we can't wait for UAs to get on board with the technology w/o
> some really great field usage.
> <m4nu>  So, what we're building is a JavaScript shim that will eventually
> be implemented natively in the browsers.
> <m4nu>  (just like JSON was, just like Persona was intended to be)
> <Odin-> Persona, with less centralisation, basically.
> <m4nu>  exactly.
> <m4nu>  One of the big problems w/ Persona was that they ended up
> spending a lot of engineering resources keeping the masking service up
> and running.
> <Odin-> Yeah, I like the idea. Big question is how to get traction.
> <m4nu>  We're going to try to make the entire thing an offline Web App...
> meaning, once you've hit login-hub.com once, you download the code, and
> then your browser caches it forever.
> <m4nu>  and the query to the network happens over Telehash (which is
> decentralized)...
> <m4nu>  so the entire masking/ email lookup mechanism doesn't require one
> website on the Internet to always be up.
> <Odin-> Only most of the time, in case someone new comes along...
> <m4nu>  re: traction - we're working on it... can't talk about the
> details yet, but we're trying to onboard a few companies that will give
> us 20M+ new users of this technology per year.
> <m4nu>  Odin-: yes, until someone new comes along, but keep in mind that
> we're talking about a pretty awful failure case (the website goes down
> and doesn't come back up for a few hours)
> <m4nu>  In the Persona case, that meant that nobody could login for a few
> hours.
> <m4nu>  In the Identity Credentials case, it means that no new users can
> create new accounts for a few hours.
> <m4nu>  The latter is a better failure case.
> <Odin-> Certainly.
> <m4nu>  and again, depending on that site is temporary until we get this
> stuff built into the browser.
> <Odin-> One question I have, though, regarding Identity Credentials and
> WebID.
> <m4nu>  Odin-: another really nice thing about this technology  is that
> your identity provider can capture any email address you want.
> <Odin-> Why not present Identity Credentials as a layer on top of WebID,
> instead of as an alternative?
> <m4nu>  For example, w/ Persona - if you identified yourself as
> odin@gmail.com, then gmail.com would have to implement Persona natively
> at some point (yes, they had some three-legged shim working, but that
> was pretty dismal)
> <m4nu>  w/ the Identity Credentials stuff, any identity provider can
> claim any email address... so, you could run a personal identity
> provider on your website and still use odin@gmail.com as your "memorable
> identifier for login"
> <Odin-> Ah, but that one depends on the telehash model. What then
> happens when the domain associated with the email decides to implement
> the protocol?
> <m4nu>  Odin-: The login-hub.com site uses the IC protocol, not Persona,
> so if the domain associated w/ the email decides to implement the
> Persona protocol, the IC stuff is unaffected.
> <m4nu>  To put it another way: A website has an option - implement
> Persona, implement IC, implement OpenID, or do all three.
> <Odin-> No, I mean the IC protocol. If you've associated an IdP with
> your email using the telehash thingy, and then the email provider starts
> using the .well-known mechanism to link emails to identities?
> <m4nu>  Odin-: by ".well-known mechanism" do you mean "the Persona
> .well-known mechanism"?
> <m4nu>  because there's the IC one: "/.well-known/identity" and there's
> the Persona one: "/.well-known/browserid"
> <Odin-> IC one.
> <Odin-> And holy hell you'd better make sure that .well-known/identity
> is _flexible_ considering how generic that name is. ;)
> <m4nu>  Odin-: We're considering removing the "/.well-known/identity"
> thing entirely, it was a pre-telehash concept.
> <Odin-> Okay. So that'd mean making the Telehash resolution mechanism
> permanent?
> <m4nu>  kinda, it would still be pseudo-temporary (unless you need to
> login from a public terminal and needed to access your IdP in a way that
> would "forget" that public terminal after an hour or two)
> <m4nu>  The browser-based implementation would probably have something an
> IdP could call to register itself as your IdP.
> <m4nu>  So, imagine you get a new computer and fire up Chrome/Firefox.
> <Odin-> But the RP needs to resolve the IdP as well.
> <m4nu>  The RP does not need to do any resolution :)
> <m4nu>  (that's another advantage of this mechanism)
> <m4nu>  All the RP does is go "Give me an email credential"
> <m4nu>  The Javascript shim then pushes the request off to login-hub.com
> (which does discovery and relays the request).
> <m4nu>  The browser-implementation would know who your IdP is (because
> you registered it w/ your browser when you setup your browser / joined
> the IdP)
> <m4nu>  The only case that's not handled is the public terminal case, in
> which case, you could use the telehash network to do discovery.
> <Odin-> How does the RP know that the IdP is associated with the email
> supplied?
> <Odin-> IOW, how do you defend against rogue IdPs?
> <m4nu>  (but you'd only need that when you're using devices which you
> don't own/use on a regular basis).
> <m4nu>  Odin-: You don't need to make that association at all
> <Odin-> Because you're actually providing the RP with a signed
> verification of your identity URI, not your email?
> <m4nu>  The only thing the RP needs to verify is: 1) Did I get a
> credential from a client that asserts that they have access to a
> particular email address.
> <Odin-> Meaning the key used by the RP will be associated with the URI,
> and not the email address..?
> <m4nu>  Odin-: You're providing the RP with a 3rd party verified
> credential... they check the signature, and if it's someone they trust,
> then you're good.
> <m4nu>  Odin-: hmm "key used by the RP" - there are a number of keys
> here, so let's be sure we're talking about the same one.
> <Odin-> Database key, not crypto key. :)
> <m4nu>  There will be 2-3 signatures on the message that the RP gets back.
> <Odin-> The RP's user lookup can't be based on email addresses if they
> can't verify the relation between email addresses and users.
> <m4nu>  The first signature will be from some authority that the RP
> trusts that effectively states "I have verified that
> https://idp.com/people/bob is associated with bob@gmail.com". The second
> signature will state "I am the IdP and I verify that the person that
> requested this credential has access to https://idp.com/people/bob". The
> third signature will state "I am a verified device of
> https://idp.com/people/bob, and I am setting the validity of this
> credential for
> <m4nu>   5 minutes and it's destination should only be RP.com".
> <Odin-> That's why Persona had the RP looking up the IdP to use. It also
> means that if the address _does_ use the .well-known scheme, you don't
> have to be familiar with the IdP to trust that it's allowed to sign.
> <m4nu>  Odin-: I'll let the above sink in, ask me questions wrt. why you
> think it might not work.
> <Odin-> The question is really about the first piece there. What does
> the RP trust, and why?
> <m4nu>  The RP trusts some set of organizations to verify email addresses
> (based on some documented/audited process they follow to verify email
> addresses).
> <m4nu>  For example, all RPs might trust the EFF, Google, Facebook, and
> W3C to not lie about verifying an email address.
> <m4nu>  So, all email verification signatures from those organizations
> will be trusted.
> <m4nu>  Does that answer your question?
> <m4nu>  (and it's up to the RP to decide who they trust if they don't
> want to trust the defaults)
> <m4nu>  For example, the Pentagon will probably only trust DoD signatures.
> <Odin-> That means you need to get a signature from one of those
> "universally trusted" organisations to create an association.
> <m4nu>  Odin-: Yes, but keep in mind that the list could be 100s of
> organizations long... or it could just be one non-profit organization
> running one open source implementation that does the verifications.
> <m4nu>  So, you (as the customer) need to only trust one of those
> organizations... and the RP needs to trust the same organization.
> <Odin-> It also means that each individual user needs to associate with
> an IdP, rather than a domain being able to provide a mapping between
> addresses and URIs.
> <m4nu>  Either that, or the RP can themselves verify and issue an email
> credential.
> <m4nu>  Odin-: Yes, each individual user does need to associate with an
> IdP, but that's not a bad thing. That's a very good thing because it
> means that users can associate themselves w/ /any/ IdP, regardless of
> which email address they use.
> <m4nu>  So, if you trusted the EFF to be your IdP, you could still use
> your gmail address w/ the EFF's IdP.
> <Odin-> It also means organisations can't associate classes of addresses
> with identities they're providing.
> <m4nu>  (you wouldn't be forced to get/use an EFF email address).
> <m4nu>  Odin-: What do you mean by "classes of addresses"?
> <Odin-> "Any address at this domain is related to an identity URI we
> provide".
> <m4nu>  Why is that important?
> <m4nu>  and by "address", do you mean "email address"?
> <Odin-> Employers wanting to associate their provided email addresses
> with a work ID might be one.
> <Odin-> Yes.
> <m4nu>  Odin-: Employers can still do that.
> <m4nu>  Why do you think they can't?
> <m4nu>  Multiple IdPs can respond to one email address.
> <Odin-> Okay, that makes identity management even trickier.
> <m4nu>  Why?
> <m4nu>  (I know why, but I'm trying to see if my "Why" is the same as
> your "Why")
> <Odin-> Because you're still thinking "which identity should I provide",
> but instead of presenting different identifiers you present different
> references.
> <m4nu>  What do you mean by "identifiers" and "references"?
> <m4nu>  (define them, because our definitions for each could be off)
> <m4nu>  Let me try and walk you through what the interface for this would
> look like:
> <Odin-> Introducing yourself by identifier is by saying "I'm so-and-so";
> introducing yourself by reference is "I'm the person John Doe knows as
> so-and-so".
> <m4nu>  We're never doing the latter (by reference)
> <Odin-> Using the same label - email address - for multiple identities
> seems complicated to me.
> <m4nu>  It's always the former.
> <m4nu>  It's not because it's a UI issue, let me explain:
> <m4nu>  You have four different IdPs that are managing identities
> associated with "odin@gmail.com".
> <m4nu>  Each one of them has a label and a picture that you've associated
> w/ the identity (that you've setup).
> <m4nu>  When you query telehash, you put in "odin@gmail.com" and some
> passphrase (let's assume it's the same passphrase for all 4 identities)
> <m4nu>  What you get back is a screen that asks you to pick one identity
> out of four (each one has a picture and a label beside it).
> <Odin-> Okay.
> <m4nu>  You pick one and go on your merry way.
> <m4nu>  (and any system that supports multiple IdPs has to be at least
> that complex)
> <m4nu>  The problem w/ Persona and OpenID is that they don't allow you to
> have multiple IdPs using the same email address... which then pushes the
> burden of remembering which email address to use for which identity off
> to the customer (which is a bad design trade-off to make)
> <Odin-> And what makes it more worthwhile for the user agent to
> implement this system rather than improving the existing TLS client
> authentication system? :>
> <Odin-> It shifts the notion away from "choice of IdPs" to "choice of
> emails". By having a concrete, explicit link between IdP and email
> address, you're effectively making it so that there is a one-to-one
> mapping of identities an email addresses.
> <Odin-> +d
> <m4nu>  re: TLS client auth system - no browser vendor is interested in
> improving that - WebID folks have been asking them for years, browser
> vendors have been saying for years that it's not a priority at all for
> them. Also, WebID TLS certs make using public terminals w/ your identity
> impossible.
> <Odin-> I'm not asking "will they do it". I'm asking "what makes this
> scheme more attractive?"
> <m4nu>  It's more attractive because:
> <Odin-> Because it is technically equivalent to the existing cert system.
> <m4nu>  no, it's not at all.
> <m4nu>  (technically equivalent)
> <m4nu>  It uses digital signatures, it does not use x509 anything.
> <m4nu>  The key distribution mechanism is the Web, not x509 certs.
> <m4nu>  more attractive because:
> <m4nu>  1) It solves the browser cold-start problem (using public
> terminals to do things on the Web in a way that's secure)
> <m4nu>  2) RPs don't have to generate/provide/manage certs.
> <m4nu>  3) You can discover keys just by doing follow-your-nose.
> <m4nu>  4) You can place Linked Data into the messages being sent between
> the systems (you can't w/ x509)
> <m4nu>  5) You can anonymize access to websites (prevent RPs from
> figuring out who you are by asking your IdP to double-blind identity
> information)
> <dlongley>      N) RPs may be more likely to implement because they can do
> so
> at a layer above TLS -- they don't have to use (or hope it's even
> available) tools to get access to what's going on in the TLS layer ...
> and/or respond within that layer to authentication requests
> <dlongley>      and if RPs are more likely to implement --- so will
> browsers
> <dlongley>      implementing TLS client-side certs is both a pain for RPs
> and
> for users (that are using browsers with poorly implemented UIs)
> <dlongley>      and that's a catch-22
> <m4nu>  which is why WebID has gone nowhere.
> <m4nu>  (and, frankly, will go nowhere)
> <dlongley>      this approach allows RPs to write software just like they
> normally do ... and it's that much easier for them to integrate
> <dlongley>      which means it will be more attractive to browsers to go
> along with it
> <Odin-> 1) Actually, no. You can build a technically similar system by
> using temporary client certificates generated on request with short
> duration. Nobody does it, because client certs are horrible.
> <dlongley>      there's a certain breaking of layers of abstraction that
> feels necessary to really get WebID working properly
> <Odin-> 2) They don't need to do that; it's just the way it's been done.
> <Odin-> 3) That's a question of setting up discovery mechanisms.
> <Odin-> I'm not saying "client certs are better".
> <dlongley>      Odin-: can you list the reasons why you think browser
> manufacturers aren't improving TLS client cert UIs?
> <dlongley>      it seems like it's a better way to investigate a potential
> answer to your question
> <Odin-> dlongley: Lack of interest in secure, decentralised authentication.
> <Odin-> What I'm asking is "why don't these factors apply here?"
> <m4nu>  Odin-: no, that's provably false :) - Mozilla persona being the
> counter-point.
> <dlongley>      so, therefore, browser manufacturers won't implement
> anything
> <dlongley>      regardless of what the solution is (for secure,
> decentralized
> auth)
> <dlongley>      do you think there is something that would make it
> attractive
> to them to implement?
> <dlongley>      btw, i think your assertion just somewhat begs the questino
> <dlongley>      it's just a restatement of the problem
> <dlongley>      the problem is browser manufacturers won't implement X
> <dlongley>      why won't they implement X?
> <dlongley>      "they don't want to"
> <dlongley>      that's not a real answer.
> <dlongley>      *why* do they lack interest?
> <dlongley>      if some Agent is not taking some action, it is obviously
> because they don't want to (when it really comes down to it)
> <Odin-> Because the big RPs are not interested, because to them, the
> privacy horrors are features, not bugs. One of the major browser vendors
> is directly a major contributor to the problem.
> <Odin-> Mozilla is somewhat unusual, but although Persona got started,
> you also can't say it was at any stage aggressively pursued.
> <m4nu>  Odin-: Wait, RPs or IdPs?
> <dlongley>      well, i think that assertion assumes that they operate as
> monolithic party rather than as separate parts
> <dlongley>      chromium developers, for example, aren't just doing
> whatever
> some Google exec says
> <Odin-> Persona also was, because of the one-to-one mapping between
> emails and IdPs, technically different from the present PKI system in
> that it did _not_ rely on trusted parties to provide the association
> between identities and keys.
> <dlongley>      i think the opinion you've put forward is slightly too
> cynical ... and assumes that these manufacturers function in a way that
> isn't fully accurate
> <dlongley>      Odin-: where was the trust in Persona?
> <dlongley>      what are "keys" in your statement?
> <Odin-> DNS and the .well-known mechanism provide a mapping between
> email addresses and IdPs in a way that does not require a trusted
> party's signature.
> <m4nu>  Odin-: You still have to trust the IdP domain to not lie about an
> email address they have.
> <m4nu>  It doesn't remove the fact that you have to trust something.
> <dlongley>      Odin-: that also forces a lock down to an IdP (or at least,
> difficulty in changing IdPs), but that's a separate issue
> <m4nu>  Odin-: You're effectively making an argument for vendor lock-in
> to an IdP.
> <Odin-> m4nu: Yes. I also have to trust their MX server to send mail to
> the right place. IOW, I have to trust them with what I'm already
> trusting them to.
> <dlongley>      Odin-: also, that is still a system where "trusted parties
> provide the association between identities and keys"
> <dlongley>      did you mean "third parties"?
> <Odin-> It forces a lock between email addresses and the domains that
> control them, a lock that _already exists_.
> <m4nu>  Odin-: I guess I don't understand what you think the issue is...
> <m4nu>  Odin-: Why do you think having that lock is a good thing?
> <dlongley>      Odin-: i'm not quite following ... one of the problems with
> Persona was that they couldn't get email providers to vouch for verified
> email addresses, Mozilla had to do it (that was my understanding)
> <dlongley>      Mozilla had to provide the trust
> <dlongley>      (and it was a centralized trust system)
> <m4nu>  Exactly, Google and Yahoo didn't want to implement Persona... and
> they held a huge sway over it's failure because of that.
> <Odin-> dlongley: Yes. As a nominally 'temporary' solution, much like
> the Telehash scheme was presented.
> <dlongley>      just because an email address goes to a domain ... doesn't
> mean that Odin owns that email address
> <dlongley>      that doesn't establish the trust, you still have to link
> identities with email addresses
> <dlongley>      Odin-: right, but there's no single centralized authority
> in
> the latter
> <dlongley>      Odin-: and there's room for other parties to come in and
> become successful at verifying email addresses or other credentials,
> etc. -- it isn't all on Mozilla, for instance.
> <m4nu>  It also doesn't automatically give Google or Yahoo a lock on 50%
> of the IdP market.
> <m4nu>  (picking 50% out of the air, but it's a large portion of the
> market that have @gmail.com or @yahoo.com email addresses)
> <dlongley>      yes, just because they have that for email doesn't mean
> they
> should have that for identity
> <dlongley>      (it's fine if it ends up that way by user choice, but it
> shouldn't be because of lock in)
> <dlongley>      (IMO)
> <Odin-> dlongley: Control of the email address is the key question here.
> <dlongley>      Odin-: IMO, it's assertion of control of an email address
> <Odin-> Should the same party who can deprive a person of an email
> address be able to break the link between an address and an identity?
> <dlongley>      being able to trust that someone really does have control
> over an email address
> <m4nu>  If you take the Persona approach you: 1) corner yourself into
> ensuring that large email providers will automatically get that chunk of
> the market (thus greatly harming competition and increasing
> centralization), 2) empower large email providers (like Google and
> Yahoo) to say "no" to decentralization as a result of enabling
> vendor-lock in via email addresses.
> <dlongley>      Odin-: ok, so your point is that for all of the services
> you
> are logged into ...
> <dlongley>      Odin-: if those services rely on the email credential only
> for identification ...
> <dlongley>      Odin-: then if your email provider drops you, you will lose
> your identity, effectively, with those services.
> <dlongley>      is that accurate?
> <dlongley>      Odin-: if so, that is not at all how these services have to
> operate (or even how a majority of them would)
> <dlongley>      instead, they'd be much more likely to store your identity
> URL as the "database key" for your identity on their service.
> <dlongley>      that you can sign in using an email address ... or provide
> that to them to handle correspondence is not relevant
> <dlongley>      in fact, likely you'd be able to change your email address
> at
> a majority of services -- just by providing a new credential for a
> different verified email address
> <Odin-> Okay.
> <Odin-> Let's back way out.
> <m4nu>  :)
> <dlongley>      Odin-: good idea -- we need to get a clearer view of the
> specific problems :)
> <Odin-> What I'm saying is this: Decoupling identity control from domain
> control forces you to have a trust match between users and RPs.
> <m4nu>  Odin-: mind if I cc this conversation to the mailing list, it
> helps explain a lot of things we've been meaning to write up.
> <Odin-> I.e., it means you have to have some group of parties signing
> email-identity mappings.
> <Odin-> I find the domain lock to be more attractive, because email
> address control is already ultimately tied to the domain controller.
> <Odin-> I'm _not_ saying that's a good thing.
> <dlongley>      Odin-: what if you want to change your email address?
> <Odin-> And, well, when it comes to Google, I'll just say that using a
> GMail address for a general identity seems folly to me.
> <m4nu>  Odin-: but you have to admit that most people that know nothing
> about security/tracking don't think it's folly. :)
> <Odin-> dlongley: I'm not saying "there should be a direct map from
> email addresses to identity URIs".
> <Odin-> m4nu: I'm also betting they haven't had secret search warrants
> issued against their GMail accounts. ;)
> <dlongley>      Odin-: if there's no direct map doesn't that involve
> "decoupling identity control from domain control"?
> <Odin-> dlongley: Not if the first-case lookup for identity providers is
> to a .well-known address for the relevant domain.
> <m4nu>  Odin-: We could do that, but what does it buy us?
> <Odin-> You're only decoupling if there is *no* reference to the domain
> in determining IdPs.
> <dlongley>      by "reference" you specifically mean "using the HTTP
> protocol"?
> <dlongley>      can "by reference" instead mean "by checking a digital
> signature from a key from that domain"?
> <Odin-> m4nu: Domain-provided IdPs don't need additional signatures to
> verify the relation between email and identity URI.
> <dlongley>      (i don't see the difference, there's still a domain lock
> there)
> <m4nu>  Odin-: "don't need additional signatures" -> why is that a
> benefit? Implementation simplicity?
> <Odin-> dlongley: That'd work. As would storing info in DNS. It just
> seems more in vogue to use .well-known, for some reason.
> <m4nu>  Odin-: You're getting a response directly from the domain that
> issues the email?
> <Odin-> m4nu: It means that at least part of the system has no
> independent trust root. You wouldn't need EFF to sign an assertion that
> "this email is related to this identity provider".
> <dlongley>      Odin-: not entirely true, what you're describing still
> relies
> on TLS, which has an independent trust root.
> <Odin-> m4nu: Although, actually, you could get the same effect by
> having the domain publish a key at a .well-known which the RP should
> trust to provide a mapping for that domain...
> <m4nu>  Odin-: That's what I was trying to get across to you before...
> <m4nu>  The RP could decide that the only signature it trusts is one from
> the email domain.
> <dlongley>      Odin-: that's almost exactly how Identity Credentials works
> <m4nu>  (and that would work just fine w/ the Identity Credentials
> spec)... except when the provider is Gmail, and they're not interested
> in doing that.
> <dlongley>      it just doesn't *require* google to do that in order for
> the
> system to function.
> <dlongley>      an RP could decide to trust someone else (or themselves)
> <m4nu>  So, to break that standoff, you allow other organizations to
> digitally sign credentials.
> <dlongley>      furthermore ... the link between email and identity URL
> doesn't have to sit out on the public internet.
> <Odin-> m4nu: The question of where that key exists is an important one,
> and when you talked about removing the .well-known scheme it sounded to
> me like taking away the obvious place to plant it.
> <m4nu>  (but it's still ultimately up to the RP to decide which
> signatures they trust: 1) Only trust the RP's signature on an email
> address, 2) Trust the RP's signature and the email domain's signature,
> 3) Trust RP, Trust email domain, plus these X other parties
> <dlongley>      Odin-: you don't need .well-known for the system to work --
> but it's fine to use it.
> <m4nu>  Odin-: Where that key exists is up to the Secure Messaging spec.
> <m4nu>  Odin-: When you get a message via Secure Messaging, the key
> location is included in the signature
> <m4nu>  Odin-: So you don't need .well-known at all for the entire system
> to function.
> <dlongley>      you follow the key URL ... (which is going to be at, for
> instance, google.com)
> <dlongley>      and that URL doesn't have to start with ".well-known"
> <m4nu>  Odin-: https://web-payments.org/specs/source/secure-messaging/
> <dlongley>      it can be whatever google feels like doing.
> <m4nu>  Odin-: Specifically, this section -
>
> https://web-payments.org/specs/source/secure-messaging/#message-signature-algorithm
> <m4nu>  and this section:
>
> https://web-payments.org/specs/source/secure-messaging/#message-signature-verification-algorithm
> <Odin-> m4nu: Ah. That's not referenced from the IC document. :p
> <m4nu>  Well, it's all built on top of Secure Messaging, yeah sorry -
> these specs are in a pretty terrible state.
> <m4nu>  We're trying to get down the more solid stuff into the specs (but
> there's only so much time in the day)
> <m4nu>  we try to verify via implementations before commiting the ideas
> to the specs,
> <m4nu>  and even then, we rev the technology every few months so the
> specs end up getting out of date (and can be a nightmare to put together)
> <m4nu>  (put together all of the concepts into a cohesive whole)
> <Odin-> Yeah.
> <dlongley>      Odin-: ultimately, the "domain lock" for trust still exists
> ... but what is locked to the domain are keys that you trust ... you can
> assume a particular key is really owned by a domain based on the
> information stated in a document you get from that domain
> <dlongley>      so that isn't lost.
> <Odin-> Well, I'm looking at this whole field partly because I find
> money to be a very interesting subject of research, and partly because
> I'm looking to build a system designed more or less solely as a user
> database for other structures.
> <m4nu>  Look at Example 13:
> https://web-payments.org/specs/source/identity-credentials/
> <Odin-> dlongley: Yes. What was missing was the fact that the domain was
> still being consulted in the process.
> <Odin-> I got the impression that it had no say whatever.
> <dlongley>      Odin-: ok, glad that's cleared up then :)
> <m4nu>  Specifically at the "creator" entry in the "signature" entry
> <Odin-> dlongley: And I would argue that there'd need to be something
> like "if the Relying Party trusts signatures other than its own to
> verify the mapping between an email address and an identity IRI, it MUST
> trust signatures by the key associated with the address's domain".
> <dlongley>      "if such a key exists"
> <Odin-> I took that as read, but yes.
> <Odin-> It'd also need to specify explicitly how to identify such a key.
> <dlongley>      well, it's important because the system can function
> without
> the key
> <dlongley>      Odin-: yes, we actually have that in implementations ...
> <Odin-> Yes.
> <dlongley>      but perhaps not yet in spec text
> <dlongley>      (how to specify key URLs to trust)
> <dlongley>      at a particular domain
> <dlongley>      it's just a linked data document you get with particular
> properties indicating the key(s) that are used to sign credentials
> <dlongley>      that may or may not ... reside at a .well-known address. :)
> <dlongley>      we've been discussing how unnecessary .well-known seems to
> be
> in a linked data world.
> <dlongley>      but that's another discussion
> <Odin-> I think it has one important use.
> <dlongley>      (ideally, you'd just get "https://google.com/" using
> Accept:
> application/ld+json and get a document with assertions about that domain
> ... some of those assertions would use an ontology that indicates keys
> to trust for credential signing, etc)
> <Odin-> If you need to "cold-boot" as it were, obtain a starting point
> for looking up information without trusting information provided elsewhere.
> <dlongley>      i'm just saying that the "cold-boot" should just be the
> root
> document of the domain
> <dlongley>      instead of ".well-known"
> <Odin-> Frankly, I think it should be stored in DNS, not served through
> HTTP. ;)
> <Odin-> That's what the damn thing is there FOR!
> <dlongley>      well, there's that too, but again, the spec will probably
> just go with what's most practical
> <dlongley>      :)
> <Odin-> Just remember that "what's practical" has a tendency to shift.
> <Odin-> RESTy interfaces were not very practical a decade ago.
> <dlongley>      true, but specs are written at a certain point in time
> <dlongley>      you have to work with what you've got
> <Odin-> Yup. Just pointing out that allowing less immediately practical
> options as well may be a wise choice in the long run.
> <dlongley>      well, certainly they can be mentioned
> <dlongley>      but if you provide too many options, you hurt adoption
> <dlongley>      which means that there will be no long run for your specf
> <Odin-> Yes.
> <Odin-> Which is why the "MUST provide an application/ld+json
> representation and MAY provide other representations" type of language
> is important IMO.
> <dlongley>      right
> <Odin-> Which brings me incidentally to a question. Is it just me, or is
> the chief _actual_ distinction between WebID and IC the choice of
> required serialisation?
> <dlongley>      no, there are more differences than just that
> <dlongley>      some of what WebID does (sans X.509, etc. stuff) is very
> similar to parts of what IC does (like verifying keys by checking
> documents from the same domain for assertions, etc)
> <m4nu>  Odin-: Keep in mind that we wrote the first few versions of the
> WebID specs :)
> <m4nu>  So, some of the similarity is because of that fact. :)
> <Odin-> It seems to me like the scheme could be split up somewhat.
> <m4nu>  which scheme?
> <Odin-> IC, and WebID. Then smushed back together.
> <Odin-> The identity documents, in particular, are actually largely
> independent of the login mechanisms.
> <m4nu>  IC, for sure - it's early days, the spec text is very experimental
> <m4nu>  Odin-: re: identity documents - yes, correct.
> <m4nu>  and we're probably going to have to separate it once this stuff
> goes REC-track at W3C.
> <m4nu>  We're just putting it in the same document for now to try to
> provide a full picture of what it can do.
> <m4nu>  Odin-: mind if I repost this discussion to the mailing list? It
> was very helpful at explaining some of the nuances
> <m4nu>  wrt. IC, WebID, Persona.
> <Odin-> And it looks to me like both WebID and IC (including the login
> mechanisms) can fairly easily be complied with by a single set of
> profile documents.
> <Odin-> m4nu: Not at all.
> <m4nu>  thx :)
> <m4nu>  Odin-: re: single set of profile documents, yes, that's true.
> <m4nu>  The login aspecs and the RWW aspects differ
> <m4nu>  s/aspecs/aspects/
> <Odin-> Wouldn't it be best for everyone to harmonize the common aspects?
> :p
> <m4nu>  oh, and the privacy aspects...
> <m4nu>  WebID doesn't protect your identity.
> <m4nu>  (An IdP can always figure out who you're logging into by what
> sort of queries it gets from RPs)
> <Odin-> That's the login part, right? I suspect that's partly because an
> implicit assumption is that people control their own IdPs.
> <m4nu>  With WebID, you login to a site... your identity URL is looked up
> via a SubjectAltName field, then the RP fetches that document. IdP knows
> that you're most likely logging into the site.
> <m4nu>  Odin-: Well, that's a terrible assumption to make given the
> overwhelming proof that people don't run their own IdPs (or websites).
> <Odin-> m4nu: Yes. But it's surprisingly common when discussing
> "distributed social networks", which seems to me to be a consideration
> driving WebID...
> <m4nu> Odin-: bottom line is - don't make that assumption. In the worst
> case, you're anonymizing against an IdP that you run. In the best case,
> you're preventing an IdP that wants to sell your data from harvesting
> all your login information.
> <Odin-> m4nu: Agreed. I don't think the WebID login mechanism is the way
> forward, but I also believe that a multitude of authentication
> possibilities is better.
>

Please could you use the correct terminology.  WebID is simply a URL that
denotes a Person/Agent.  WebID+TLS is an authentication system.

Also, the certificate UI *is* being worked on.  As someone that uses it
100s of times a day on 3 browsers, I am seeing a constant evolution.  Sure
it's not #1 priority (why would it be?), but there is some exaggeration
going on here, imho.

Odin is right.  WebID and IC are pretty much the same thing except for the
mandated serialization ie Turtle vs JSON-LD.  My guess is that in time most
system will support both, making this issue go away.

The only other difference is that Manu seems to have an issue with the
dictionary definition of "Agent" which is used to describe a Person,
organization, group or machine.  This does not seem a compelling reason to
create a fork in the core identity spec.  If the term "Agent" is a
show-stopper, we need to know that, and come to a consensus.


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
>