Web Payments Telecon Minutes for 2014-02-05

Thanks to David I. Lehn for scribing this week! The minutes
for this week's Web Payments telecon are now available:

https://web-payments.org/minutes/2014-02-05/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2014-02-05

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0030.html
Topics:
  1. Updating Website w/ Charter and Work Items
  2. Web Identity Updates
  3. HTTP Signatures
Chair:
  Manu Sporny
Scribe:
  David I. Lehn
Present:
  Dave Longley, Manu Sporny, David I. Lehn, Joseph Potvin, Evan 
  Schwartz
Audio:
  https://web-payments.org/minutes/2014-02-05/audio.ogg

Dave Longley is scribing.

Topic: Updating Website w/ Charter and Work Items

Manu Sporny: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0001.html
Manu Sporny:  The voting is complete, we had a decent turnout, 
  typical turnout for small w3c items is 0.5-1%, for larger votes 
  its around 25%, we had 19% - so, that's good.
David I. Lehn is scribing.
Manu Sporny:  Results of charter vote were good, we now have a 
  charter. 19% show up rate for charter. Good turnout.
Manu Sporny:  Not much is going to change about how we operate 
  (because the charter formalizes what we've been doing for the 
  past several years) but we have the charter written down now.
Manu Sporny:  Posted charter on community page - 
  http://www.w3.org/community/webpayments/charter/
Manu Sporny:  Two editorial changes. Wrong link to community and 
  business process. Link to SWIFT removed per discussion last week.
Manu Sporny:  Each of the work item are listed in the charter 
  now.
Joseph Potvin: Manu Is talking w/ a few legal teams from large 
  organizations and they will advise if there are any issues.
Manu Sporny:  Of the work items, the HTTP Signature nonces had 
  least support, which is not surprising. Everything else had good 
  support.
Manu Sporny:  We could draw a few conclusions based on how people 
  voted and what the priorites are.
Joseph Potvin: We Could conclude that higher number voting 
  suggests priorities for workplan.
Joseph Potvin:  The voting rate may suggest priority but also may 
  indicate level of understanding of a topic.
Manu Sporny:  Yeah, we shouldn't read too much into the number 
  wrt. votes having to do w/ priorities, it's just one input to the 
  decision plan.

Topic: Web Identity Updates

Manu Sporny: https://web-payments.org/specs/source/web-identity/
Manu Sporny:  We're working with another company that's part of 
  the group to figure out how to include other information with an 
  identity.
Manu Sporny: Web Identity works with OpenID or Persona, once you 
  login, the login mechanism transmits the identifier
Manu Sporny:  Should be able to do login via OpenID or Persona 
  and be able to go get more information about an identity.
Manu Sporny:  Two primary things you want in an identity. Easy to 
  use object. Things like name, phone number, citizenship status, 
  etc.
Manu Sporny:  If a government has signed a identity or similar, 
  need to have a mechanism to get this info. So, that's the second 
  thing you want - to be able to get ahold of the assertions.
Dave Longley:  Signatures in payments work on assets and listings 
  were done by normalizing data and storing signature along with 
  data.
Dave Longley:  Similar for identities, but with one small 
  difference - Store data and assertions on the data.
Dave Longley:  Assertions from government or other authority. 
  Data will be signed by that entity and signature included with 
  assertion. Then the assertions will be merged with the identity 
  object.
Dave Longley:  The identity object will include all the 
  information related to the identity and all the assertions 
  related to that information.
Dave Longley:  We can use the JSON-LD flatten feature to get all 
  the data together in an easy to use object.
Dave Longley:  If you want to check particular data, you can go 
  through list of assertions and find who signed a piece of data.
Manu Sporny:  Here's an example of an identity: 
  https://web-payments.org/specs/source/web-identity/#a-typical-identity
Manu Sporny:  Changes we'll need to make - we'll add a property 
  called "assertion" with an array of assertions.
Manu Sporny:  Each assertion will have a type such as 
  NameAssertion, AddressAssertion, EmailAssertion, or 
  PassportAssertion. It will also include something called an 
  "endorsement", that is the information on the identity that 
  you're asserting.
Manu Sporny:  The entire assertion will be signed. If government 
  signs a digital passport, can use the email or web identity url. 
  That ties assertion to identity.
Manu Sporny:  Electronic passport would assert name, birtdate, 
  country, etc.
Dave Longley:  Here's an example of what this would look like in 
  practice: https://gist.github.com/dlongley/8827309
Discussion Related to the design of the assertion and endorsement 
  object.
Dave Longley:  The 'id' in endorsement needs to be the identity 
  id so the flatten process works.
Manu Sporny:  Mozilla badges system ties data to email address, 
  so I don't know if this will work for something like that.
Manu Sporny:  It's a bad idea to use an email because our email 
  addresses change over time, we don't want to lose that data just 
  because our email address changed.
Discussion About issues with how much data to be in endorsements 
  and how to avoid leaking too much data.
Evan Schwartz:  Could you have the government sign each piece of 
  the identity and then sign some kind of group object that links 
  all of the fields they've signed together?
Manu Sporny:  I don't think we need the group signed, because the 
  JSON-LD flattening process takes care of collating the data 
  together. The issue is with granularity, if you have a passport 
  that signs your name, government ID, and birthday and a site asks 
  for just your birthday, you don't want to give them all of your 
  passport assertion information. You just want to give them 
  information related to your birthday. So, the government is going 
  to have to provide multiple assertions - one each for name, 
  birthday, and government ID and one for all of that information 
  bundled together plus a few other passport-specific details.
Manu Sporny:  Website could request information, but person could 
  decide to not send certain information, then website could decide 
  if they want to continue
Evan Schwartz:  I do think we should go that way.
Dave Longley:  Yes, put the onus on websites to break the chain.
Manu Sporny:  So, we need to clarify how assertions and 
  endorsements are made in the spec based on this discussion.
Manu Sporny:  Do we want non-signed assertions to be made?
Dave Longley:  May not be useful and could pollute the data 
  model.
Dave Longley:  If a 3rd party wants to assert something you 
  should provide proof you made the assertions.
Dave Longley:  People can make assertions about themselves, the 
  assertion is assumed and doesn't have to be signed.

Topic: HTTP Signatures

Manu Sporny:  We pushed a new HTTP Signatures spec out last week: 
  https://web-payments.org/specs/source/http-signatures/
Manu Sporny:  We got feedback from Julian, who is the editor of a 
  ton of HTTP specs at IETF and really knows his stuff: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0018.html
Manu Sporny:  And feedback from Mark, the Chair of the HTTP 
  working group: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0019.html
Manu Sporny:  These guys really know what they're doing so we 
  need to make a number of the changes they've asked for and 
  respond to them sooner than later.
Manu Sporny: Let's Cover Julian's feedback first - 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0018.html
Manu Sporny:  Confused if we define a HTTP Authentication scheme. 
  We want this to work for both client-to-server and 
  server-to-client scenarios, so we may want to not use the 
  Authentication scheme and define our own HTTP header.
Manu Sporny:  Julian says that we should align with algorithm 
  names. Unfortunately, IETF specs used different naming for 
  algorithms. JOSE vs DKIM etc. I'm going to ask Julian what should 
  be used.
Manu Sporny:  Headers param. request-line change to 
  "(request-line)" can break current deployed code.
Dave Longley:  Should do something that works better with HTTP/2
Manu Sporny:  We might just have to specify how the header line 
  is canonicalized
Manu Sporny:  Item 4 extensions - removing the section, we have a 
  better way of doing extensions now in the spec.
Manu Sporny:  Item 5 - point to a proper base 64 spec, going to 
  do that.
Manu Sporny:  Item 6 - field values, We want to avoid 
  canonicalization. proxies might do strange things to headers. 
Dave Longley:  Might be able to use x- headers as a work around 
  for proxies, we might want to spec that.
Manu Sporny:  Item 7 - point to digest spec, yep, we'll do that
Manu Sporny:  Item 8 - error handling. how to handle multiple 
  values. use last value wins?
Dave Longley:  Whenever multiple occurances not allowed, last 
  wins, done.
Manu Sporny:  Where to send feedback? just use web payments list? 
  I think just use the web payments mailing list since it's not an 
  official HTTP Auth WG item.
Manu Sporny:  Fix cite and other misc issues
Manu Sporny:  On to Mark's feedback, his email is here: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0019.html
Manu Sporny:  We want to change the name of the spec and make the 
  editorial changes he is asking for.  We want to avoid 
  canonicalization if we can, but may not be able to do that for 
  the request line.  Regarding the 401 Unauthorized + 
  WWW-Authenticate, we don't really want to provide that but I 
  doubt the spec will make it through the process w/o it, so we 
  might as well add it.
Manu Sporny:  Anything else we need to cover for this call?
No Other business mentioned.
Manu Sporny:  Thanks, we may not have call next week.

Received on Wednesday, 5 February 2014 18:47:04 UTC