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

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.

-- 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/

Received on Friday, 30 May 2014 19:13:50 UTC