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

Credentials CG Telecon Minutes for 2015-02-10

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


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

  1. Introduction to Laura Fowler
  2. Introduction to Brent Shambaugh
  3. Web Payments IG Face-to-Face
  4. Decentralized Identifiers for Credentials/Badges
  5. Signatures Update
  6. Badge Alliance Context/Vocabulary Update
  7. Roadmap Update
  Manu Sporny
  Dave Longley and Manu Sporny
  Dave Longley, Manu Sporny, Nate Otto, Laura Fowler, Brent 
  Shambaugh, elf Pavlik, Brian Sletten, Victoriano Giralt, Eric 
  Korb, Mary Bold, Kerri Lemoie

Dave Longley is scribing.
Manu Sporny:  We have a discussion on decentralized identifiers 
  we're adding to the agenda as the second item.
Manu Sporny:  Anything else to add?
Nate Otto: I updated the vocabulary section of Mark's roadmap doc 
  a small amount. 
  -- could be part of the Badge Alliance JSON context update.

Topic: Introduction to Laura Fowler

Laura Fowler:  I'm a principal enterprise architect for ETS. I've 
  been asked to sit on this meeting in place of Bill Gebert. He's 
  unable to join on a weekly basis, I'm sitting in for him and 
  working with our teams on badges and credentials.

Topic: Introduction to Brent Shambaugh

Brent Shambaugh:  I've been spending the past year or two with 
  the Web Payments CG, I'm here because I'm looking at applications 
  to enterprise and engineering tools and integrating Linked Data 
  with those things and payments too.

Topic: Web Payments IG Face-to-Face

Manu Sporny: 
Manu Sporny:  The minutes should be out for the F2F Web Payments 
  IG meeting in Utrecht in a week or so.
Manu Sporny:  There's a summary link in IRC for an overview of 
  what happened.
Manu Sporny:  Overall, we were expecting 18 people and around 30 
  showed up. We had a lot of great representatives there from large 
  corps, including GSM, Rabobank, Bloomberg, National Association 
  of Convenience Stores, World Pay, etc. big major players in the 
  space. As far as credentials stuff is concerned, we went in 
  making a case that credentials are important for the payments 
  work, specifically for KYC and anti-money laundering and 
  regulations, etc. and in general the group agrees.
Manu Sporny:  And we were able to get some fairly loose consensus 
  around three items, 1. creds are important for payments, the 
  group feels that a credentialing component must be exist to 
  standardize web payments, 2. regulations can't easily be met 
  without credentials, 3. if the Web Payments IG creates a WG for 
  credentials, the work should be done in an independent WG just 
  for credentials
Manu Sporny:  The group wants to look at the use cases we've done 
  here which is really good. So it's all great news, we got what we 
  wanted to out of the F2F meeting.
Manu Sporny:  We weren't able to spend much time looking at the 
  roadmap and use cases, but in general, the Web Payments IG would 
  like to work more closely with the Credentials CG over the next 
  few months. We've got some work to do for any official work that 
  might start up around the credentialling initiative.
Manu Sporny:  Any questions or concerns?
Manu Sporny:  The one thing we may want to do differently from 
  what we've been doing here. We've been focusing on technical 
  stuff, but at some point W3C will want us to propose some kind of 
  charter to float around W3C membership. We also want to start 
  trying to get votes from the membership for this work. We've got 
  400 organizations we can make contact with and see if they'd like 
  to support a WG charter for credentials.
Nate Otto: Exciting progress. Thanks for travelling.

Topic: Decentralized Identifiers for Credentials/Badges

Manu Sporny is scribing.
Manu Sporny:  Nate, do you mind giving us some background?
Nate Otto:  A discussion came up on Badge Alliance standards 
  board about ways to identify documents in a badge storage 
Nate Otto:  One contributor is frustrated w/ badge issuers that 
  are hosting multiple documents, much like identity document, 
  sometimes descriptions are changed, he wanted a GUID.
Nate Otto:  I remember the @id is a part of the Open Badges 
  spec... we will have a unique identifier in the form of an IRI, 
  so that will be compliant.
Nate Otto:  There may be a DNS-like infrastructure to look up 
  badges back to the "document of truth".
Nate Otto:  Not sure if that's useful vs. just using IRIs. 
Nate Otto:  We also had a discussion around the Experience API 
  (xAPI). The xAPI group is building in support to transport 
  badges. Looks like they built that spec off of the Activity 
  Streams 1.0 spec. Looks like they've diverged from AS 2.0.
Nate Otto:  So far, it's not JSON-LD...
Manu Sporny:  We have a lot of thoughts in this area. We're 
  concerned about vendor lock-in, we don't want vendors to create 
  badges and then keep people from being able to move their badges 
  around and choose where they store them, etc. We, meaning 
  "Digital Bazaar" is concerned that using IRIs could lead to 
  vendor lock in. [scribe assist by Dave Longley]
Dave Longley:  We have been talking about decentralized 
  identifiers to prevent vendor lock-in. We want stuff to be 
  portable, been talking about this in Web Payments for years.
Dave Longley:  We've been referring to them as "DID"s - 
  decentralized identifiers. We've explored a couple of ideas like 
  DNS-like systems, blockchain-like systems, decentralized query 
  systems, etc.
Nate Otto: I saw a demo of the "telehash" approach last summer.
Dave Longley:  Distributed hashtables to look up names - Manu 
  wrote a blog post at some point.
Dave Longley:  You can do a query on a network to find pieces of 
  information. All these sorts of ideas try to solve the same 
  problem. How do you have an identifier for you badge / identity? 
  Can you change where that information is stored? Can you have an 
  opaque identifier?
elf Pavlik: Which post? identity credentals one?
Manu Sporny:  Elf-pavlik, yes, the Identity credentials one.
Dave Longley:  So there are a number of things we've been 
  discussing related to decentralized identifiers.
elf Pavlik: For the record 
Dave Longley:  So, with the credentials work, we want some way to 
  prevent vendor lock-in. We want to make portability possible.
Nate Otto:  Two points, I guess - we were thinking about using 
  IRIs - low barrier to entry, everyone can resolve them. In order 
  to prevent lock-in, we have this "authorization to issue on my 
  behalf" credential?
Nate Otto:  Maybe identity can generate another ID - then 
  authorize other platforms to issue badges for them.
Nate Otto:  Re-up on the authorization after a certain time 
  period - prevent vendor lock-in, without needing a technical 
  spec. A lot of the people that are issuing badges are probably 
  not going to be keen on building in telehash or blockchains yet.
Nate Otto:  My main focus is to try to moderate BA mailing list - 
  when questions get too big for badge alliance - like "what do we 
  do for identifiers" - I want to push those questions into this 
  group - into larger spaces.
Nate Otto:  We want to adopt larger technologies - ones that are 
  more general.
Dave Longley:  With regard to people controlling their own domain 
  - difficult for most people to do - but many people want to be 
  able to control their own identity - they're going to end up 
  using a domain that is not in their control. We don't want them 
  to be locked into those "identity providers" or "credential 
  storage systems". They're going to use a 3rd party to store their 
Dave Longley:  And we want them to be able to move away from that 
  provider. We can't rely on HTTP IRIs for it - I don't think we'd 
  deviate from using IRIs... but they might not be HTTP IRIs, you 
  might have to resolve them in a different way - coming up with 
  another system that has a lower barrier to entry. People 
  shouldn't have to buy a domain to be in control of their own 
Dave Longley:  There are several other layers of abstraction here 
  - we don't think of vendors as ones that store badges, there's a 
  dichotomy there - there is an issuer who can create the badges, 
  then there is another organization that might store the badges.
Dave Longley:  There are several different components that could 
  be combined into one entity, or they could be split out. Issuers 
  wouldn't need to implement telehash. Someone could say "This is 
  my DID", and then that's it. the issuer issues to that DID.
Dave Longley:  There are different layers of abstraction that we 
  could put in to make it easier for issuers.
Nate Otto:  So a service dedicated to transport things between 
  HTTP IRIs and some other telehash-like IRIs. 
Dave Longley:  Yeah, there are a number of different ways that we 
  could achieve this - we want data portability, we want to make it 
  easy for people that don't have their own domain to still be in 
  control of their identity.
Nate Otto:  Sounds like excellent goals - the ability to have the 
  conversation here is good - we want to push this question out of 
  BA mailing list to here.
Nate Otto:  My immediate "TODO" question - as we think about 
  identity and identifiers - what should we do to make sure we'll 
  be compatibile with something like this.
Dave Longley:  We expect this stuff should go into Identity 
  Credentials spec or a companion WebDHT spec.
Dave Longley:  As far as creating documents/badges - as long as 
  you're using JSON-LD and badge IDs are IRIs... what we will be 
  creating, I think, are interfaces and protocols to indicate how 
  to write to someone's personal set of credentials. That's the 
  space that should be followed more closely.
Brian Sletten:  I support and agree with the larger intiative of 
  data portability - and a telehash-like identifier. Is there a 
  certain credential use case where people don't care about 
  portability. The organization that's issuing it - if issuer is 
  not in control of it, they don't care.
Brian Sletten:  Can we just fall back on resolvable IRIs - is 
  that acceptable?
Dave Longley:  It's a design goal, it's not a design reality. Any 
  sort of DID would be at a different identifier. You'd say "use 
  this IRI" to write to my identity.
Dave Longley:  So, the issuer would assign credentials to a DID.
Nate Otto: Most of our issuer organizations in the Open Badges 
  world are orgs with their own websites... often the heavy lift is 
  to do the editing on that site on a regular basis, not just 
  getting and continuing to pay for the domain. So they are using 
  badge-specific issuing platforms. A one-time site edit to add 
  authorization doesn't seem too difficult for an organization in 
  this case.
Dave Longley:  At a high-level, issuers would use HTTP to 
  write... at a low-level, you can use a DID.
Dave Longley:  If we can make it easy for everyone to use a DID, 
  we want to standardize on that. your point is well taken - we 
  don't want to make this difficult for folks.
Example of URL-based identifier: https://dev.payswarm.com/i/manu
Example of decentralized identifier: 
Manu Sporny:  One addition to that, I agree with Dave Longley's 
  comments and Brian you make a good point, we don't want to make 
  issuing badges an arduous thing. That's not the proposal, rather, 
  when you log into an Issuer Website, you give them your ID, today 
  with OBI that's your email address or salted email address, etc. 
  That's rev 1. In the future, we want to issue badges to a 
  dereferencable URL. I could log into an issuer site, for [scribe 
  assist by Dave Longley]
Dave Longley: Example, using the URL in IRC. I could assign the 
  badges to that URL. The downside is that once those badges are 
  issued to that website I'm locked into it. If that site goes away 
  or deletes my identity, etc. my badges are gone unless I can 
  somehow prove I once owned that URL. Now we're saying you could 
  tell the issuer, that instead of using HTTPS, please use my DID.
Manu Sporny:  Any badge assigned by the issuer would go to that 
  DID and there's a lot of complexity underneath that (hidden away) 
  and we want to make it as easy to use as possible. [scribe assist 
  by Dave Longley]
Manu Sporny:  In the case that we fail to create a good 
  decentralized id mechanism we just fall back to URLs [scribe 
  assist by Dave Longley]
Nate Otto: The Badge Alliance is extremely sensitive to issues 
  that make the user experience difficult for credential 
Manu Sporny:  The downside is we're going to create vendor 
  lock-in; where there are very few badge "vaults" and little 
  possible competition. W3c has created standards over 20 years 
  that have vendor lock-in because the basic identifier mechanism 
  leads to it. [scribe assist by Dave Longley]
elf Pavlik:  XDI is important - we should look at iName and 
  iNumber - you pay for it... iNumber always stays with you - 
  domain name doesn't expire. We could look at how XDI works - 
  would be happy to invite him to the discussion.
Victoriano Giralt:  Do you know about OrcID? I wouldn't promote 
  it - it's vendor lock in - unique identifier that you give to 
  authors - so you can tell one "John Smith" from another "John 
  Smith". You should be able to move that around with you.
Victoriano Giralt: Orcid.org
Victoriano Giralt:  I'm not supportive of that, because of vendor 
  lock-in - but maybe we can learn from it since they're becoming 
  big in academic environments.
Manu Sporny:  There are a number of orgs that are setting 
  themselves up as identifier organizations. GS1 is an example of 
  this, barcodes, and IDs like that in the world, etc. What we're 
  trying for here is a decentralized mechanism where you get to 
  issue your own identifiers and claim them instead of having a 
  centralized org do it for you. We don't want to create these 
  super orgs that just hand out IDs to people. We think we have a 
  bett [scribe assist by Dave Longley]
Dave Longley: Er infrastructure this time around to solve this. 
  We couldn't solve this in 80's and 90's as easy, but today we 
  have a global community infrastructure that can generate IDs in a 
  way that doesn't conflict, etc. The Internet, instead of creating 
  an org that sucks up several million dollars a year and just 
  issues IDs.
elf Pavlik: 
  you can find Markus Sabadello on list of Credentials CG 
Victoriano Giralt: Big applause from me to manu
Nate Otto:  One of the other possibilities in Badge alliance - 
  issue directly to public key? It is a solution to make sure 
  things are decentralized, we'd have to build up quite a workflow 
  around how to prove identity.
Victoriano Giralt: PGP web of trust?
Manu Sporny:  One of the other things that came out of F2F, 
  Ripple Labs and Ethereum were there, they've been involved in the 
  bitcoin work as well, there was a lot of discussion around 
  identifiers, blockchain tech and so forth. All these techs are in 
  the same basic area and it's going to take some time for 
  consensus for the right approach. Overall goal is prevent vendor 
  lock in and make it easy to use, if it's not easy it won't be 
  used. [scribe assist by Dave Longley]
Dave Longley:  One more quick thing - we've discussed how to use 
  public keys to generate identifiers - there are a couple of 
  drawbacks in the identity space... in Bitcoin, you don't care 
  what your address is - if you have a problem, you just generate a 
  new identifier and move your money over.
Dave Longley:  You might want to keep that identity for a really 
  long time - if public key is compromised, how do you do that?
Dave Longley:  It's a much bigger problem than just switching 
  addresses - a  lot of your credentials are now linked to that 
  identifier, but now that identifier is no good. It's a trickier 
  business to switch keys. Generating IDs directly from 
  cryptosystems have bigger rammifications on identity than 
Eric Korb:  More of a question than a statement - vanity domains 
  - like .ceo - people are using those as identity - all those 
  systems would be able to offer identity piece once we have this 
  identity system sorted.
Victoriano Giralt: Elf, i'd say yes
Eric Korb:  We don't want people to create identity for 
  themselves at great expense.
Dave Longley:  It's not clear that we should go that path - layer 
  on top of DNS - most people don't own their own domains. We want 
  lower barrier to entry - don't pay for an ID.
Eric Korb: Such as erickorb.ceo which is part of the 
  peoplebrowser platform.
Eric Korb: +1 Manu, that's what I wanted to come out.
Manu Sporny:  If we want this thing to be ubiquitous, we can't 
  say that you have to spend even $7/year to buy an identifier. 
  People won't necessarily want to spend that money for just a 
  couple credentials and some people can't, and we want to reduce 
  the amount of friction for creating a domain. Any one of those 
  those .ceo, .me domains is a non-trivial amount of money in 
  kenya, ethopia, even some people in the US dont' want a vanity 
  URL, etc. [scribe assist by Dave Longley]
Manu Sporny:  That's why facebook and twitter are so pervasive, 
  they don't have to pay anything and they can jump in and claim 
  their URL. The problem is lock in. [scribe assist by Dave 

Topic: Signatures Update

Dave Longley: 
Dave Longley:  There are some brief updates to simpler algorithms 
  that are a part of the normalization algorithm.
Dave Longley:  Update to Quads - a quad is an RDF statement Joe 
  knows Phil Graph0.
Dave Longley:  Joe is the Subject. knows is the 
  predicate/property. Phil is the Object. Graph0 is the graph 
  containing the statements.
Dave Longley:  So, this is a short sub-algorithm and brief update 
  to the spec at this point.
Manu Sporny:  How much more work is left?
Dave Longley:  I need a solid week to work on the spec 
  exclusively - just a weeks worth of work on it - it's taking a 
  while because I don't have much time to work on it.

Topic: Badge Alliance Context/Vocabulary Update

Nate Otto:  We have made a few changes over last couple of weeks 
  - changes will be reflected in document in next week.
Nate Otto:  One of the main changes - additional terms - adding 
  previous property to a badge, must be matched to a JSON-LD 
  statement, we want to be compatible with Linked Data Signatures. 
  Anyoen could implement LD signing mechanism as an extension. A 
  valid JSON-LD data that could be added to a badge.
Nate Otto:  We're changing references to the word from "standard" 
  back to "specification".
Nate Otto:  We made update to vocabulary document - term names.
Nate Otto:  The first thing - claim - property/value pair. 
  Credential class - badge class is a specific set of claims issued 
  as one set to many recipients so people can observe that many 
  recipients received the claims.
Nate Otto:  BA thinks that there is a lot of value wrt. who has 
  what set - endorsement work, a way for a 3rd party to endorse a 
  badge class - say "this particular class has value".
Nate Otto:  A Credential collection - grouping of credentials.
Nate Otto:  Identity, which is an IRI acting as a common 
  identifier - issuer, requester, endorser, etc.
elf Pavlik:  Could you tell me a bit more about a collection? Is 
  there paging concerns, etc?
Nate Otto:  We haven't come up with how they will be delivered. 
  Identity credentials does list JSON-LD representations of 
  credentials... paging hasn't been addressed in that spec. 
  Basically, you have a JSON-LD array. I don't think paging has 
  been addressed.
Manu Sporny:  I think elf, you're alluding to the Linked Data 
  Platform Container stuff, it means something very specific there. 
  Are you asking a question about the difference between a 
  Collection and a Container? [scribe assist by Dave Longley]
elf Pavlik:  Just wondering about the functionality - 
Nate Otto:  Good question - I think one of our earlier use cases 
  had to do w/ composition of credentials. One particular 
  credential might not have enough information wrt. having enough 
  information to prove something. 3-4 different validated 
  statements presented together in format that could be understood.
Nate Otto:  Analyze trust relationship - powerful case to look 
Dave Longley:  One point with respect to format for identity 
  credentials - we designed with that in mind. If you look at the 
  spec, the way the spec is laid out - each credential makes claims 
  about a particular ID. The @id is the IRI for the identity. Each 
  credential - the @id property is also the identity.
Dave Longley:  You can take all the credentials and merge via 
  JSON-LD framing - check signatures, run through framing, and has 
  a complete merged identity object for use.
elf Pavlik:  Could you make an example on the playground and send 
  to mailing list?
elf Pavlik:  That would be helpful.
Dave Longley: You're correct, it's not
Nate Otto: 
  vocabulary document
Nate Otto:  There is the work on that document.
Nate Otto:  Also other work will be on a new domain... probably 
  up later this week.
Eric Korb: @Nate is there a product road map for 2015 for OBI?
Nate Otto: I'll forward that question along to BA staff, @ekorb

Topic: Roadmap Update

Mary Bold:  We need to go back through use cases and look at 
Nate Otto: On the roadmap, Mark wants to develop a timeline in 
  the near term.
Manu Sporny:  Any other business?
Manu Sporny:  Roadmap document looks good, we just need to start 
  filling up the gaps [scribe assist by elf Pavlik]
Received on Tuesday, 10 February 2015 18:36:43 UTC

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