W3C home > Mailing lists > Public > public-credentials@w3.org > October 2015

Credentials CG Telecon Minutes for 2015-10-13

From: <msporny@digitalbazaar.com>
Date: Tue, 13 Oct 2015 13:10:53 -0400
Message-Id: <1444756253692.0.24008@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Gregg Kellogg and Dave Longley and Manu Sporny for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

http://opencreds.org/minutes/2015-10-13/

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

----------------------------------------------------------------
Credentials Community Group Telecon Minutes for 2015-10-13

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2015Oct/0006.html
Topics:
  1. NACS Show
  2. HTTP Signatures
  3. Introductions to New Members
  4. W3C TPAC Credentials DRAFT Presentation
  5. Credentials Reference Implementation Demo
  6. Post-meeting Discussion
Organizer:
  Manu Sporny
Scribe:
  Gregg Kellogg and Dave Longley and Manu Sporny
Present:
  Gregg Kellogg, Manu Sporny, Brian Sletten, Henry Story, Carla 
  Casili, Chris Webber, Dave Longley, Tim Holborn, Eric Korb, John 
  Tibbetts, David I. Lehn, Annie Janssen, Rob Trainer, Richard 
  Varn, Nate Otto
Audio:
  http://opencreds.org/minutes/2015-10-13/audio.ogg

Gregg Kellogg is scribing.
Manu Sporny:  Expecting to do some intros today, but they don’t 
  seem to be on the call.
  … We can look at the W3C TPAC presentation and then go into 
  demo.

Topic: NACS Show

Brian Sletten:  Just got back from Las Vegas and spoke to NACS 
  about credentials, and they are interested.
Manu Sporny:  Anything we should do/change as a result of your 
  presentations? Are we aligned with their expectations?
Brian Sletten:  Nothing to change, they now know that there is 
  something interesting going on here, tried to get some of them to 
  join.

Topic: HTTP Signatures

Henry Story:  Also have stuff to talk about.
Manu Sporny: We reved the spec - 
  https://tools.ietf.org/html/draft-cavage-http-signatures-05
Henry Story: Ah good thanks
Manu Sporny:  We have a new version of the HTTP Signatures spec, 
  with minimal changes so it won’t expire. We had a bunch of emails 
  that it had expired and concerned that we wouldn’t take it 
  forward.

Topic: Introductions to New Members

Carla Casili:  You may know me from Mozilla and Open Badges, noew 
  working with IMS Global.
  … We’re looking at interop within education. We’re looking at 
  Digital Credentials and metadata/criteria needed to build-out 
  Open Badges.
  … There are three different teams working on this, with about 5 
  months to go. We’re looking at frameworks and requirements for 
  interoperability.
Chris Webber: Would it be useful for me to give a brief 
  introduction?
Chris Webber:  I’m Chris Webber, working on the W3C Social Web 
  WG. We’re working on ActivityStreams/JSON-LD federation standard 
  for having an experience between decentralized sites. Credentials 
  are important for this.

Topic: W3C TPAC Credentials DRAFT Presentation

Manu Sporny: 
  https://docs.google.com/presentation/d/1ithW3t-ahelw_0jsAbVmhXi5NyRl_-BAW6hMnJmoixc/edit?usp=sharing
Carla Casili: Hey everybody. Glad to be here. If you would like 
  to connect my contact information is as follows. email: 
  ccasilli@imsglobal.org ; twitter: @carlacasilli ; skype: 
  cmcasilli
Manu Sporny:  We’re prepping for two presentations at the end of 
  October at TPAC. There’s one on the credentials work; it tries to 
  summarize the survey we sent out; we’re up to 43/60 responses.
  … There’s also data on the anonymized results.
Manu Sporny: Anonymized results of survey (43 responses): 
  http://opencreds.org/presentations/2015/w3c-tpac/anonymized.html
  … The responses are randomized and specifics made generic. 
  There are a bunch of graphs which are also in the presentation 
  that underscore the types of capabilities people are looking for.
  … We lead among all the groups that are discussing next-gen 
  payments and related activities.

Topic: Credentials Reference Implementation Demo

Manu Sporny:  The demo shows the entire credentials eco-system.
  … The eco-system has 3 major actors: issuers (e.g., DMV, 
  Passport, Education Institutes …).
  … Also Identity Providers who store credentials on your behalf. 
   About anyone can become a provider.
  … And the third group are credential consumers, those who need 
  to see credentials for some form of proof (access to bank 
  account, completion of degree, …).
  … The goal of the group is to be sure that each of the actors 
  plays in a level playing field, and interoperability is key.
  … The demo shows all 3 actors operating; it’s focus on TPAC 
  specifically for the interest of payments.
  … They’ll re-visit the discussion that was tabled over the 
  summer.
  … The first demo is payment-specific. The second is more 
  open/free on Wednesday, that talks about education/healthcare 
  concerns.
  … Entry point is to create an account on an Identity Provider 
  (IDP), such as Google/Facebook/Twitter, but could be school or 
  business.
  … (shows creating an account)
  … Where it deviates from normal sign-up, you get a popup for a 
  polyfill, which gives you a decentralized identifier. The 
  credential is assigned to something that is portable, different 
  from email or social media addresses. This allows the solution to 
  be user-centric so the user is responsible for their own 
  credentials, and not tied to something owned by someone else.
Tim Holborn: +1
Chris Webber: Are there links to more decentralized identifiers 
  stuff?
Chris Webber: It being not linked to domains sounds great
Dave Longley:  My comment is to point out that the window that 
  pops up is something that would be standardized in the future.
Henry Story:  You’re thinking of this as part of the credential 
  management API.
  … Is the identifier are URL or a URI?
Tim Holborn: V.bad echo. please turn down speakers...
Dave Longley:  It’s intended to be a URL or URI with the “did” 
  scheme, that can be fetched.
Chris Webber: I have a question once henry's question is resolved
  … The reason for a new scheme is to create a way of specifying 
  decentralized identifiers. Http URLs are tied to a specific 
  location, so are not appropriate.
Henry Story:  If you loose your private key, you can loose 
  access.
Dave Longley:  We can talk about that later.
Manu Sporny:  We can also use HTTP URLs, but if you don’t have 
  control of the URL (which you can’t really), that is compatibile 
  with this sytem. We thing that DIDs are a great solution, though.
Chris Webber: Interesting
  … Also, if you lose your PK, you can delegate access to the DID 
  to other people or organizations, so that even if you loose your 
  PK, you can update the document with a new key. We don’t thin 
  this suffers from the kinds of problems BitCoin suffers.
Chris Webber:  This sounds interesting. Where are these stored, 
  and what is ussed to retrieve a DID?
Manu Sporny:  In the future, they’ll be on a WebDHT; this 
  technology has been around for around 15 years. We need to bring 
  the technology on the web Rather than create a new protocol, we 
  can build it on top of HTTP/HTTPS.
  … The way it’s stored is in a DHT, and retrieved using HTTP to 
  hit nodes in the DHT to find the data you’re looking for. In the 
  Polyfill, it’s sotred on authorization.io, with a REST-based API. 
  THat will continue to be exposed in the future.
Henry Story:  It will be interesting to make sure we can do this 
  in an orthogonal way, so that WebID could be based on this.
  … We should make sure that HTTP/HTTPS onion-URLs follow the 
  same kind of process so that people can choose the type of system 
  the like, with competition/creativity among providers.
  … IF the main notaion of a WebID is a reference to a person, 
  then it’s powerful enough to cover all these kinds of cases.
Tim Holborn: Does WebID = Agent? or Legal Entity? or Person?
Tim Holborn: FYI: http://www.w3.org/wiki/WebID
Dave Longley:  What you’re saying is inherent in the design. It’s 
  like a WebID with a URL you follow to get information about the 
  person. There’s a concept of a DID you can choose, so that it 
  follows you around instead of being tied to a particular domain. 
  We support any kind of URL, but we’re showing the DID concept.
Manu Sporny:  We’re proposing what we think the ideal is, but 
  make sure that it’s open to other solutions.
  … (continues demo) Creating a DID, stored in the browser local 
  storage. This returns a DID back to the IDP.
  … (account created, associated with DID), now I can create 
  credentials)
  … (goes to another site which is an credential issuer). It 
  requires that I log in, and I use my DID.
  … YOu can use crypto, selecting identity (from local storage), 
  which completes login.
  … I then get a drivers licence (shows JSON-LD representation of 
  DL, tied to DID).
  … It has several claims (name, image, birthdate, gender, 
  address, …)
  … Also includes signature linking to DMV as signer.
  … You create the Credneital and it goes back to IDP, who stores 
  credentials. The signer has no idea what IDP is used to store the 
  credential.
  … Middle-ware intermediates moving the credneital between 
  sites, so it’s never used to connect one service with another 
  directly. You can store PII once things are complete, so that it 
  can’t be later hacked.
Tim Holborn: What do browsers need to do to make this work if 
  anything?
Chris Webber: I don't have questions, but I think I need to get a 
  list of all relevant specs
Chris Webber: And read through them
Eric Korb: That's ekorb SIP
Henry Story:  You go do the DMV, login with your ID (DID), they 
  sign a document saying that the person with the DID has various 
  properties. The browser accepts the Cert in the browser, where it 
  can be stored at an IDP, or stay in the browser.
  … When someone asks for your DL, you can send it from your IDP 
  or browser.
Tim Holborn: Cheers\
Eric Korb: Dlongley, joim.me info?
Tim Holborn: https://join.me/digitalbazaar
Manu Sporny:  Goes to a credential consumer. You create a bank 
  account, they can pre-fill information by submitting a drivers 
  licence, a cert version can ensure that information is not 
  fraudulant.
  … I submit my DL, it goes back to middleware, where I select my 
  identity, which takes me to my IDP. They see that someone has 
  asked for the DL, but they don’t know who.
  … If it know who was asking, they could violate your privace. 
  The IDP gets a request, and the user can select it in their 
  browser, with verifiable data.
  … I click “done”, and the browser takes the credential back, 
  and asks to be sure to send it back to requester, and the user 
  sends the credentials from the browser.
  … I send it to the bank, and it can verify it, and proceed with 
  signup.
Gregg Kellogg:  What does the bank need to do to verify that 
  credential. [scribe assist by Manu Sporny]
Manu Sporny:  First step is to check basic syntactic validity. It 
  can then fetch the PK, to be sure it matches.
  … It checks to be sure the issuers signature is valid, but 
  needs to be sure the issuer can be trusted.
  … It’s up to the recievers to choose the issuers they trust. 
  For an example, for an international DL, the US might trust it’s 
  alies, but not someone else. THey would have a list of 
  organizations they accept credentials from.
  … There could be deepter information, link-back to issuer to be 
  sure it’s not revoked, but no link back to IDP.
Nate Otto: +1 On that countersignature by the credential's 
  recipient.
  … The credential is counter-signed by the holder of the 
  credential in addition to the issuer. The holder signs when the 
  send it to a consumer.
  … This prevents replay attacks.
Henry Story:  If there’s a way for the consumer to say what kind 
  of credentials the accept (who they trust), so the client can 
  filter among stored credentials.
Dave Longley:  We’re looking into that; they could specify 
  properties of credentials they want, and may also show the set of 
  issuers they trust.
John Tibbetts:  I still find it hard to visualize are the 
  workflows among the parties. This would be a great topic of a 
  future Manu-Cast.
  … Say I have a credential that asserts my age, I have a phone 
  and go into a bar to order a date. What would the transaction 
  look like?
Manu Sporny:  There’s a privacy component to your question, you 
  really don’t want to reveal anything other than your age. Not 
  even exposing your DID.
Eric Korb: 6 Points of identity
Eric Korb: Plus, photo id
  … To get the credential, you go to an issuer, who proves your 
  identity (utility bill, SS card) and may issue multiple 
  credentials to you. It could be afull passport, but also a 
  credential simply asserting your age.
  … When someone needs to know your age, you could show just the 
  credential that asserts the miminum they need to know.
  … Another approach is called a “Bearer Credneital”, that can 
  prove something in a pseudo-anonymous way. This would allow a 
  single use of something that didn’t actually assert your ID.
Tim Holborn: Does a mechanism exist that discourages groups from 
  demanding more information from a credential than is required for 
  legal purposes?
Dave Longley is scribing.
Manu Sporny:  Yes and no. The way that the system works right now 
  is that the consumer queries for a set of attributes that they 
  need to know about you.
Eric Korb: So, at the liquor store, they would have you scan a QR 
  code that would request your ID.
Manu Sporny:  So if they just need to know your name the query is 
  just name and you're taken to the IdP to prove your name. Your 
  Idp shows you 20 creds with your name. We're hoping the software 
  and the people make it obvious that you pick the credential(s) 
  with the least amount of information. It's up to you to decide 
  what you ultimately hand over.
Tim Holborn: Given the potential explosion in identity requests, 
  has any consideration been made into reputation?
Tim Holborn: Ie: perhaps using ontologies to describe what might 
  be required to fulfill particular requests.
Eric Korb:  A privacy question: As a best practice, I suspect 
  that we would not want people to publish credentials on a public 
  website that contain their DID. If they did they could be 
  tracked. If I publish my driver's license on linked in then 
  people could track me with any credential I ever put out there.
Manu Sporny:  Maybe, it just depends on how public you want that 
  particular identity to be. You can have many identities. Maybe 
  it's your public identity and you get credentials for it and 
  publish those and you don't have a problem with exposing that 
  information.
Tim Holborn: Ie: if an adult website or online game, that may 
  simply require name or proof of age, requests more information 
  for say - ‘free credits’ , perhaps reputation plays a role?
Manu Sporny:  There may be requirements to keep things hidden, 
  however, sometimes. Like any healthcare credentials.
Tim Holborn: I imagine part of that is beyond the scope of 
  credentials spec.  Yet support for ontological functional 
  adaption may need to be included?
Manu Sporny:  There isn't a clear answer to the question, it 
  follows practices of today, some things you want public and some 
  things you want private.
Eric Korb: So, that makes a case for multiple IdPs
Carla Casili:  You answered some of the questions I had, one was 
  about atomic level credentials, not needing everything in a 
  credential, just a few bits of information. So my other question, 
  your provider is saying "Here are five credentials that are being 
  requested of you." I'm wondering about the owner of these 
  credentials and how people juggle that? Will IdP help handle 
  that, if so how?
Manu Sporny:  There is a competitive marketplace for IdPs and one 
  of the factors would be how well they help you select the 
  credentials to use.
Manu Sporny:  An Idp could say this is the credential you should 
  share because it exposes you the least amount of information. 
  Another might say "You use your driver's license all over the 
  Web, just go ahead and use it again."
Manu Sporny:  It's up to IdP software to compete to help you the 
  way you want.
Eric Korb:  By default credentials are private, you have to make 
  them public by choice.
Manu Sporny:  Yes.
Tim Holborn: Privacy by default; for the entire credential? or 
  for elements of the credential? is it all or nothing?
Henry Story:  What I was thinking of is, I suppose one reason for 
  integrating the IdP in the browser is that if you authenticate to 
  one site with 3 different credentials, then in fact they can get 
  the sum of that information. If the IdP doesn't know who you are 
  connecting then it can't help you make certain decisions. It 
  seems like you'd need that sort of thinking for automation.
Henry Story:  On the other side, imagine if you had different 
  IDs, one for your age, one for your driver's license, one for 
  membership of a club, you could have other credentials that 
  identify those? You could have as many of those credentials that 
  identifier (owl:sameAs relations).
Manu Sporny:  Yes we want to automate these processes as much as 
  possible.
Dave Longley:  Quick response - there are other technologies out 
  there that don't fully provide all features that we need. Some of 
  these other protocols, the way the protocol is designed requires 
  the IdP to know all sites you're logging into. [scribe assist by 
  Manu Sporny]
Dave Longley:  You can provide the IdP with where you're logging 
  into, but that is not shared by default. [scribe assist by Manu 
  Sporny]
Tim Holborn: Here
Tim Holborn: Has any consideration been made into reputation?
Tim Holborn: Ie: perhaps using ontologies to describe what might 
  be required to fulfill particular requests.
Tim Holborn: Ie: if an adult website or online game, that may 
  simply require name or proof of age, requests more information 
  for say - ‘free credits’ , perhaps therein a mechanism around 
  reputation might play a role?
Tim Holborn: Thereafter: i imagine part of that is beyond the 
  scope of credentials spec.  Yet support for ontological 
  functional adaption may need to be included?
Tim Holborn: Therein; by privacy by default; is that for the 
  entire credential? or for elements of the credential? is it all 
  or nothing?
Manu Sporny:  "Are there any ontologies for requests?" The 
  requests use linked data so we can arbitrarily extend them in the 
  future as needed.
Manu Sporny:  RIght now they are attribute based.
Manu Sporny:  Yes, you can have reputation-based credentials, 
  absolutely.
Tim Holborn: I mean...
Tim Holborn: Mailing list it...
Manu Sporny:  I don't know what you mean by "ontological 
  functional adaption"
Manu Sporny:  When it comes to a credential itself, it's all or 
  nothing (in terms of privacy), because of the limits of 
  cryptography at the moment. We can ask issues to atomize the 
  information as much as possible.
Dave Longley:  It's all-or-nothing right now, there are 
  cryptographers working on getting around this but there are lots 
  of limitations right now.
Manu Sporny:  It's up to people in the market to create and 
  publish reputation ontologies and issues to use them, etc.
Tim Holborn: Sorry - i copy and pasted it to make it easier for 
  you…  cheers.  i’ll follow-up on the list.
Henry Story:  What is the relationship with HTTP signatures?
Manu Sporny:  They are designed to give you access to this 
  system. They are meant for machines or agents to be able to 
  access Websites.
Dave Longley:  The flow that we showed today is a browser-based 
  API [scribe assist by Manu Sporny]
Dave Longley:  In the future, you may give automatic access to 
  certain credentials to certain consumers - in those systems, 
  where you are preauthorized, there are the issuers and consumers 
  - they use HTTP Signatures to authenticate. [scribe assist by 
  Manu Sporny]
Tim Holborn: Is it possible to make hierarchical credentials that 
  create in effect a package of crednetials?
Tim Holborn: Ie: a drivers license is made up of several child 
  credentials…?
Tim Holborn: Ie: Age, Address, DL ID, etc.
Chris Webber: Very helpful!
John Tibbetts: Very helpful
Manu Sporny:  Any other questions send to the mailing list, 
  hopefully this was helpful to everyone and to understand the flow 
  for where we are today.
Tim Holborn: Thank you…  good to see ;)
Manu Sporny:  Thanks everyone for the call today!

Topic: Post-meeting Discussion

Manu Sporny is scribing.
Dave Longley: Mediaprophet, you could provide the same 
  information a driver's license provides by combining other 
  credentials together
Tim Holborn: Yup
Tim Holborn: That was what i was thinking
Tim Holborn: So, the DL ends up being a credential package
Dave Longley: When a consumer requests attributes, what you 
  essentially do is what we've been calling
Dave Longley: "Compose a view of your identity"
Dave Longley: You pick N credentials ... and those, together, 
  will provide the attributes requested
Tim Holborn: Therein; if someone needs Proof of Age, perhaps the 
  Sig. on the Age constituent is an element
Tim Holborn: Yet.
Tim Holborn: For trust purposes, they might want the age you’ve 
  listed on your DL
Dave Longley: So what gets sent to the consumer is an "identity 
  document" with a bunch of credentials ... which, with JSON-LD 
  processing ends up being a doc with a bunch of attributes on it 
  for use
Dave Longley: Anyway, this stuff is all linked data, so it's 
  fairly flexible
Dave Longley: We don't know what people will want to put in these 
  credentials and we don't pretend to know it ... so we get out of 
  the way and let people innovate.
Tim Holborn: Understood…  With a Digital Cinema Package or DCP.
Dave Longley: We just want to ensure interop ... and then let 
  markets evolve as needed.
Tim Holborn: https://en.wikipedia.org/wiki/Digital_Cinema_Package
Tim Holborn: It’s basically got a bunch of files in it.
Tim Holborn: I think it’s best i follow-up on the mailing list.
Tim Holborn:  Ok [scribe assist by Dave Longley]
Tim Holborn: It’s also 3:19am here.  so probably better in the 
  morning ;)
Dave Longley: Yes :), gnight!
Tim Holborn: Cheers.  really enjoyed the demo.
Dave Longley: Great :)
Chris Webber: Indeed
Chris Webber: Really interested in exploring further
Chris Webber: Just downloaded 
  http://opencreds.org/specs/source/identity-credentials/ to my 
  e-reader, will read over tonight
Chris Webber:  Be warned that's pretty out of date. [scribe 
  assist by Dave Longley]
Tim Holborn: I think the simple version, is that i’m thinking 
  about a tree structure.  So the child results are simple claims 
  like age, etc.  the parent record might reference those claim 
  documents and use them to create a ‘parent’ claim, for example - 
  drivers license.  Theory being around whether it’s possible to 
  in-effect create a credential where a check-box (for instance) 
  could be used to select that ‘age’ element, of a DL.
Chris Webber: Dlongley, is there newer material I should read?
Dave Longley: Paroneayea, don't pay attention to any of the REST 
  API stuff.
Tim Holborn: Being that it is part of the ‘trust provider’ 
  delivered by the motor authority
Tim Holborn: Yet, don’t need to supply the entire claims chain, 
  contained within the parent cred.
Dave Longley: Paroneayea, if you want to know about the API used 
  in the demo: 
  https://github.com/digitalbazaar/credentials-polyfill
Dave Longley: The stuff in the Identity Credentials spec 
  regarding how things are marked up isn't too far off
Henry Story: I suppose one question is how does the idp send the 
  credentials to the Relying Party? In OpenId it is via a redirect, 
  but that requires a URL with encoded attribute values. Is there 
  another way?
Dave Longley: It's worth reading that spec anyway, just know that 
  a lot of what was in the demo hasn't been updated in the spec
Dave Longley: Mediaprophet, there are certain limitations based 
  on cryptography for plucking out bits of a doc
Tim Holborn: Understand.
Tim Holborn: Yet, question might be whether you can create a 
  cred. that incorporates other creds.
Henry Story:  With the browser API, the IdP sends them to the 
  browser [scribe assist by Dave Longley]
Dave Longley: Via a JS API
Tim Holborn: And thereafter package them in some way...
Henry Story: Is that a new API?
Dave Longley: Bblfish, 
  https://github.com/digitalbazaar/credentials-polyfill
Dave Longley: Bblfish, yes, it's a new API ... we're slowly 
  converging with the Credential Management API
Dave Longley: This demo was our largest move towards it ... we're 
  not too far off now.
Henry Story: Great.
Dave Longley: Essentially `navigator.credentials.get()` is called 
  on the consumer site ... just like the Credential Management API
Dave Longley: It returns a Promise that will resolve, eventually, 
  to the credentials (or "identity document containing 
  credentials") selected at your IdP
Dave Longley: After you go through the flow.
Dave Longley: Similarly, you call `navigator.credentials.store` 
  at the issuer site to store something ... it returns a Promise 
  that will resolve once you've done something at your IdP.
Dave Longley: And this is all polyfilled with postMessage and 
  iframes and such.
Dave Longley: (Full source available at that link)
Dave Longley: https://github.com/digitalbazaar/authorization.io
Dave Longley: Also open source^
Dave Longley: That's the code the `authorization.io` site runs 
  that acts as the part of the browser that would run the flows and 
  display your IdP and so on.
Tim Holborn: Nb. before manu picked-up the questions, i copy / 
  pasted them, trying to make it easier…  so in effect, there’s 
  duplicates
Received on Tuesday, 13 October 2015 17:11:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:25 UTC