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 Log
Dave Longley is scribing.

Topic: Updating Website w/ Charter and Work Items

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: 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.

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.