Re: Mozilla Persona and Web Payments Telecon Minutes for 2013-10-09

Thanks for posting the minutes. Interesting stuff.

I was indeed interested in replacing JWT with JSON-LD for navigator.mozPay() because it solved a lot of problems in how you can link data with URLs and external contexts. However, I still want to wait until there are at least as many JSON-LD developer libraries as there are for JWT (or at least a few more major languages). It sounds like that will happen very soon.

-Kumar

On Oct 9, 2013, at 2:38 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Lloyd Hilaiel, from the Mozilla Persona identity team, and I found a bit
> of time to talk about payments, persona, and identity this morning. The
> goal of the discussion was to figure out how we could leverage the
> Persona work for the identity work we're doing in the Web Payments
> Group. I think we were largely successful in finding a solution that
> wouldn't complicate Persona and that would work for the Web Payments
> identity requirements.
> 
> The call was recorded and minuted to make sure that others that need to
> know this information have easy access to it:
> 
> https://payswarm.com/minutes/2013-10-09-persona/
> 
> Full text of the discussion follows for archival purposes at the W3C.
> Audio of the meeting is available as well (link provided below).
> 
> --------------
> Web Payments & Persona Telecon Minutes for 2013-10-09
> 
> Agenda:
>   http://lists.w3.org/Archives/Public/public-webpayments/2013Oct/0026.html
> Topics:
>   1. Persona, Identity, and Payments
>   2. JSON-LD vs. JOSE
>   3. JWT support for Extended Attributes.
> Present:
>   Manu Sporny, Lloyd Hilaiel
> Audio:
>   http://payswarm.com/minutes/2013-10-09-persona/audio.ogg
> 
> Manu Sporny is scribing.
> 
> Manu Sporny: To be clear, the part of the Agenda that this call
>   is about is item #4: Identity and Payments
> 
> Topic: Persona, Identity, and Payments
> 
> Manu Sporny:  Thanks for taking the time to talk about Persona /
>   Financial Identity. Would you like some background before we
>   start?
> Lloyd Hilaiel:  High-level background would be great.
> Manu Sporny:  I just spent a considerable amount of time at world
>   banking conference. it gathers all 6,900 international banks
>   under one roof to talk about issues. One of those is bank
>   standardization. Banks have an issue with identity
>   standardization right now, it's expensive, not standardized at
>   all, etc. Know Your Customer verification covers government
>   issued ID, you're not on terrorist watchlist, etc. When someone
>   walks into a bank branch, they keep having to verify people and
>   pay for it.
> Manu Sporny:  It would be better to have a bring your own
>   identity mechanism - get an assertion from the government that
>   says they're a citizen or live at a particular address, when they
>   need to prove that, they can just provide that assertion to the
>   service. We'd like to figure out a way to extend Persona in a way
>   that is simple, but provides richer identity mechanisms for banks
>   and financial institutions.
> Manu Sporny:  We have a way that Persona could provide a
>   bootstrapped mechanism into this, but we need to know if what we
>   need to do is do-able.
> Manu Sporny:  What we were going to do was to say that the
>   financial institution should become a Persona identity provider.
>   The financial institution gives them an e-mail address, like
>   lloyd@paypal.com.
> Manu Sporny:  When you go to login to a site that you want to buy
>   something, or prove that you have a particular shipping address
>   or govt. ID, you'd login w/ Persona and the assertion provided by
>   the bank would include extra data. For example, an identity URL
>   that is compatible with the Web Payments standards. It could
>   contain a bitcoin address, etc. The question we have is - is that
>   in the persona design? Could an identity provider include other
>   information that the identity consumer could use to bootstrap a
>   discovery process.
> Lloyd Hilaiel:  I think the answer is yes.
> Lloyd Hilaiel:  Let's be clear. This would be data in the
>   certificate asserted by PayPal.
> Manu Sporny:  Yes, they could also be endorsements by a 3rd
>   party, but let's keep it simple for now and say that only PayPal
>   is making the assertions.
> Lloyd Hilaiel:  Yeah, you could include other data signed by
>   other people.
> Lloyd Hilaiel:  There is a concern here about information
>   leakage.
> Manu Sporny:  Yes, we're concerned about information leakage. For
>   example, in PaySwarm you can have multiple identities and each
>   one of those identities is going to have information that you
>   want to share and information that you don't want to share. In
>   some cases you want people to know your shipping address, in
>   other cases, you don't want people to know your shipping address.
> Lloyd Hilaiel:  So, shipping address is something that might be
>   in some certs and not in others.
> Manu Sporny:  Yes, but let's not go that far. All we want to do
>   is provide some sort of bootstrapping mechanism. So, the only
>   thing we're talking about emedding in the Persona assertion is a
>   URL. If they want to find out more information, they go through
>   something like an OAuth token request to get the shipping address
>   or govt ID number. Whoever owns the identity is going to make
>   that decision.
> Manu Sporny:  That won't be part of the Persona process. All we
>   need Persona to do is to assert a payment processor identity URL.
>   So, to answer your question, we're not going to put any
>   information in there that could leak personal details about that
>   person (into the Persona certificate).
> Lloyd Hilaiel:  One could imagine extensions to Persona to allow
>   other data to be embedded in the certificate. Identity providers
>   need to make sure that they don't leak information. Maybe they
>   can select between multiple certificates.
> Lloyd Hilaiel:  In the beginning, if there is information that
>   the identity provider is comfortable embedding in the
>   certificate, then I think we're talking about a very small change
>   to add extended attributes to Persona. I thought that already
>   existed in Persona.
> Lloyd Hilaiel:  The only thing you need is extended attributes in
>   Persona assertions... is that correct?
> Manu Sporny:  yeah, that's all we'd need. The line we're talking
>   about adding looks like this: paymentIdentity:
>   "https://dev.payswarm.com/i/manu"
> Lloyd Hilaiel:  We need to refresh our JWT implementation and
>   conform w/ the latest version of JWT, it would be interesting to
>   understand the ext parameter to view expected attributes.
> Manu Sporny:  I think that was pulled out, but maybe I'm
>   mis-remembering.
> Lloyd Hilaiel:  As a follow-up, let's look at JWCrypto to see how
>   difficult it would be to add it (if it's not already there). Then
>   we can just let a thousand flowers bloom.
> Lloyd Hilaiel:  There is an interesting related use case, we're
>   using Persona internally at Mozilla, our identity provider
>   ensures that only people that should be able to see data can see
>   it. Our systems require canonical email, so that could be extra
>   information added to the payload as far as Mozilla is concerned.
>   That would be a good test.
> Lloyd Hilaiel:  There is a line here that you have to walk, you
>   could cause users to expose information that they never wanted to
>   expose.
> Manu Sporny:  Yes, we have the same sort of issue in the Web
>   Payments world. For example, we have anonymous identities that
>   only the identity provider and the customer know about. Someone
>   outside the system wouldn't be able to track that anonymous
>   identity back to the person. To be clear, we still follow the
>   letter of the law, you can be a government and demand to know who
>   the anonymous identity is, but only a legal mechanism can extract
>   that information. So putting the anonymous identity and a
>   real-world identity together in a Persona assertion would be a
>   terrible thing.
> Manu Sporny:  Yes, so information leakage is a big issue, which
>   is why we only want to do, at most, one extra line in the Persona
>   assertion. The more information you add, the more combinatorial
>   information leakage issues you face.
> Lloyd Hilaiel:  This brings up another issue. We would like to
>   encourage identity providers that use site-specific
>   pseudoanonymous identifiers that you can choose to eliminate and
>   remove from your own identity. In order to enable this, Persona
>   would need to give the site a deterministic, user-specific,
>   site-specific string/token so that they could reliably generate a
>   site. That's one case where leaking/fingerprinting that the
>   identity provider can't track where you can go on the Web. It's a
>   tension that we haven't been able to figure out. You may want to
>   do a deal with your identity provider to give you information to
>   specific sites.
> Lloyd Hilaiel:  A specific certificate that is specific to a
>   particular target origin, that's a tricky call.
> Manu Sporny:  Some identity providers are going to provide that
>   functionality because it eases the whole experience.
> Manu Sporny:  Look at payments on the web. There are many cases
>   where people don't want to be bothered w/ typing out their
>   shipping address. In the Web Payments case, Amazon.com could make
>   a request to an identity URL to pull shipping information. It's
>   like giving them an OAuth token to get your address information.
>   So, the shipping address assertion wouldn't live in the Persona
>   assertion, it would live in another database/process outside of
>   Persona. Then Amazon.com could ask for the shipping address by
>   making a direct query against the identity provider, and if
>   they're in the access control list, the identity provider gives
>   the information to Amazon.
> Manu Sporny:  Specifically, in the web payments case, that is
>   going to be the norm. The person that has the identity and the
>   identity provider, they will authorize certain sites to get data
>   w/o their continouous authorization.
> Manu Sporny:  There are other things that come into play wrt.
>   what sort of information it can give out and/or protect. This is
>   all really complicated and specific to the use cases. Either
>   Persona is going to take all of these use cases into account, or
>   you're going to have to push these features into another spec
>   that deals w/ this sort of stuff.
> Manu Sporny:  There are many organizations that require an
>   identity mechanism that can contain SSNs and government ID
>   numbers.
> Manu Sporny:  My assumption to this point is that Persona team is
>   primarily focused on the basic login problem.
> Lloyd Hilaiel:  As of today, yes, that's correct. We don't want
>   to blow up the Persona spec, we want to layer stuff on top. We
>   want to solve the login/auth problem in a way that's forwards
>   compatible. Let's solve the 80% case, a simple protocol that can
>   be built into browsers.
> Lloyd Hilaiel:  I think this boils down to being able to have
>   extensions in the Persona assertion, it allows freedom to
>   experiment.
> Manu Sporny:  So, I think that we can be a canary in the mine as
>   far as extended attributes are concerned. We'd really like to use
>   Persona for the identity mechanism. it doesn't make sense for us
>   to do something ourselves. We're going to push Persona and we'll
>   try to add the extended attribute stuff. Seems like you're saying
>   that there is a desire to work on that sort of thing in the
>   future. If it's a simple mechanism, like using extended
>   attributes in a JWT, then problem solved. It also shows that
>   Persona can be extended to handle the more complex identity use
>   cases.
> Lloyd Hilaiel:  Yes, I'm going to look at the code.
> 
> Topic: JSON-LD vs. JOSE
> 
> Manu Sporny:  the other thing I wanted to discuss was the use of
>   the JOSE stack vs. JSON-LD:
>   http://manu.sporny.org/2013/sm-vs-jose/
> Manu Sporny:  That's going to be a much more difficult
>   discussion, because it could result in a lot of work for you
>   guys.
> Manu Sporny:  We've been working w/ the Mozilla Badge team about
>   JSON-LD. JSON-LD has gotten a good bit of pickup - Google is
>   using it in Gmail, IBM is using it for Activity Streams. There
>   are ways of doing digitally assigned assertions that is better
>   than the way it's done in JOSE. JSON-LD could express Persona
>   assertions and other things that we've been talking about,
>   express it more simply, etc.
> Manu Sporny:  We're also talking w/ Kumar at MozPay, I think we
>   convinced them to switch to JSON-LD right before they decided to
>   drop MozPay in preference of a secure frame. We have a pretty
>   decent track record of approaching people using JOSE and talking
>   about benefits of JSON-LD over JOSE. The ability to add arbitrary
>   data into Persona assertions would be a big benefit. Now, the
>   downside is ripping out JWT and putting in JSON-LD could be a
>   considerable amount of effort. One potential option here is that
>   we support JWT and JSON-LD in the Web Payments Persona identity
>   solutions. We're using JSON-LD for all of the other messaging on
>   the network, if we could provide the assertions in JSON-LD, then
>   that would be great for the Web Payments stuff.
> Manu Sporny:  Even if its the Web Payments based websites use
>   JSON-LD version of Persona.
> Lloyd Hilaiel:  I'm skimming your blog post right now, the
>   comparison looks very thorough. For us, there are some format
>   changes we want to make in the coming months. Stuff like hex in
>   some places, base-64 in some places. Being able to have multiple
>   keys as an Identity Provider, you can do key revocation and
>   change keys in a way that has no user impact.
> Lloyd Hilaiel:  If you have a breach, then pull the key, you're
>   good.
> Manu Sporny:  yes, and that's the sort of thing you can do in
>   JSON-LD easily. We have a Web-based PKI mechanism which is really
>   nice.
> Manu Sporny:  When you digitally sign something, you use
>   web-based key, so for example:
>   https://dev.payswarm.com/i/manu/keys/4
> Manu Sporny:  So, JSON-LD is very web-based, more than JOSE.
> Manu Sporny:  I just wanted to make sure that we could at least
>   have a discussion about it.
> Lloyd Hilaiel:  Is anyone else on Persona team aware of this?
> Manu Sporny:  I posted the link once, but I don't think anyone
>   read it because you guys are pretty busy.
> Lloyd Hilaiel:  Ok, I'll take two actions - look at extended
>   attributes, and look at JSON-LD. We want something more formal by
>   the end of the year. Now is a great time to read the blog post
>   and consider what this would look like.
> Manu Sporny:  If you need any details, JSON-LD community would be
>   happy to help.
> Manu Sporny:  That's pretty much all I had for today. Extended
>   attributes can be done. JSON-LD/JOSE discussion can be pushed off
>   until you guys are ready to talk about it.
> Manu Sporny:  Thanks so much for taking the time to chat about
>   this stuff.
> Lloyd Hilaiel:  Sorry that it took so long to sync up.
> Manu Sporny:  You guys are doing an absolutely fantastic job w/
>   Persona, we're really impressed with it. Keep up the great work!
> Lloyd Hilaiel:  Thanks!
> Manu Sporny:  I'll go back to the Web Payments group, tell them
>   the plan to use Persona. We'll devise the technical details of
>   how we're going to do this, and then we'll implement Persona as
>   the login mechanism for the Web Payments stuff.
> Lloyd Hilaiel:  Great, we're here to support you, just let us
>   know how we can help.
> 
> Topic: JWT support for Extended Attributes.
> 
> Lloyd Hilaiel: so Manu, when I look at the jwt spec, it seems
>   like the provision for extensions are discussed here:
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-12#section-4.2
> Lloyd Hilaiel: so if an IdP were to embed additional properties
>   in a jwt "certificate", those would be additional claims.
> Lloyd Hilaiel: if our code were not hostile to such claims, then
>   it seems like the mechanisms required are present
> Lloyd Hilaiel: does my read sound right to you?
> Manu Sporny:  ah, yes... now I remember reading that when I did
>   the review. thanks! So, in the very worst case, we'd register a
>   new Public Claim Name in the JSON Web Token Claims Registry for a
>   payment identity URL, which could then be used to boostrap deeper
>   identity claims (like govt. issued ID numbers, address
>   information, etc.)
> Lloyd Hilaiel: yes, and you would have 3 chars to make that claim
>   discoverable
> Manu Sporny:  Lloyd, I think you're read is correct... we'll keep
>   going down that path until something blows up on us.
> Lloyd Hilaiel: Manu, ok, when it blows up, ping me.
> Manu Sporny:  Will do.
> Manu Sporny:  Thanks a ton lloyd - we have what we need to make
>   progress now.
> Lloyd Hilaiel: my pleasure!
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Meritora - Web payments commercial launch
> http://blog.meritora.com/launch/
>

Received on Thursday, 10 October 2013 16:18:59 UTC