Re: Web Payments Telecon Minutes for 2014-02-05

On 5 February 2014 19:46, <msporny@digitalbazaar.com> wrote:

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

Thanks for posting this.

On this example, "email" is defined via the @context as foaf : mbox

http://xmlns.com/foaf/spec/#term_mbox

mbox is of type owl : Thing whereas, the example is a literal.

Note also that mbox is an Inverse Functional Property.  I also wonder if
there's are any edges in payments where two people might share a single
email address...


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