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

Credentials CG Telecon Minutes for 2015-08-11

From: <msporny@digitalbazaar.com>
Date: Tue, 18 Aug 2015 10:48:51 -0400
Message-Id: <1439909331078.0.19645@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Dave Longley 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-08-11

  1. Introduction to Annie Jenssen
  2. Recruiting
  3. Roadmap
  4. Credentialing Capabilities and Current Proposal
  Manu Sporny
  Dave Longley
  Dave Longley, Manu Sporny, Annie Janssen, John Tibbetts, Richard 
  Varn, Eric Korb, Brian Sletten, Matt Stone, Brendan Benshoof, 
  Nate Otto, Rob Trainer, David I. Lehn

Dave Longley is scribing.
Manu Sporny:  We're adding one agenda item which is an 
  introduction by Annie Janssen from Parchment.
Manu Sporny:  Any other changes?

Topic: Introduction to Annie Jenssen

Annie Janssen:  Hi, Annie Jenssen - product manager at Parchment. 
  Parchment is primarily an e-transcript company, we have a 
  conusmer company - parchment.com. We have lots of highschools 
  using transcripts - I manage consumer-side of things. Website 
  where highschoolers can log on. Right now adding other credential 
  types. We've partnered with CLA so students can order their 
  credentials, diplomas, certifications, other types of academic 
Manu Sporny:  Great, welcome to the group. Are you joining the 
  group long term or are you just joining in? What do you hope to 
  get out of the group over the next couple of meetings?
Annie Janssen:  I'm joining the group - joining community groups 
  to get an idea of what's going on in the Credential landscape. 
  Working on consumer side, want to make sure I'm in the loop with 
  everything that's going on in the credentialing world. [scribe 
  assist by Manu Sporny]
Manu Sporny:  Awesome. Any other questions for Annie before we 
  move on?

Topic: Recruiting

Manu Sporny:  We need to another round of pings to make sure 
  people have seen the recruiting questionnaire and they will it 
Manu Sporny:  The other thing that is happening right now is this 
  case that we're making to W3C that credentials are worth doing. 
  The first two blog posts are done.
Manu Sporny:  We've got a bunch of background material in the 
  second post that strengthens the arguments made in the first 
Manu Sporny:  I've circulated this with people that will be on 
  the call to discuss in the next couple weeks.
Manu Sporny:  If you can send me feedback so I can make 
  changes/updates to it that would be great. Initial response from 
  W3C staff has been that it's good and they are appreciative of 
  all the background research that went into it.
Manu Sporny:  For those joining late, we've got another 60 orgs 
  that haven't responded yet and we need to ping those.
Manu Sporny:  We need Matt Stone, John Tibbetts, Eric, to re-ping 
  people on the list.
Manu Sporny:  We need responses to the questionnaire.
Manu Sporny: This is the form that we're asking organizations to 
  fill out: 
John Tibbetts:  I'll be seeing some of these people next week. I 
  can talk to them then.
Manu Sporny:  That would be fantastic.
Manu Sporny:  Any other updates on recruiting?
Richard Varn:  I got a phone call, Gary from ETS and I, and we 
  talked with Accenture and they'll run it up the poll and get back 
  to us about joining. They were worried about time commitment and 
  I told them to not worry about committing a technical expert for 
  every meeting, etc.
Richard Varn:  We met with IMS Global and met with someone who is 
  running their credential effort there. They are having 
  initiatives about competency based education another on 
  credentials. It was "Carla Casilli".
Richard Varn:  She's leading the work there now.
Manu and korb had presented to Carla.
Carla is have a session at IMS next week on Tuesday.
Richard Varn:  She's inviting the right people, etc. She 
  mentioned you've talked with her.
Manu Sporny:  Eric and I did a presentation with her around July 
Richard Varn:  They will kick off their calls and discussions 
Manu Sporny:  Thanks for the update Richard, fantastic news on 

Topic: Roadmap

Manu Sporny:  There's one huge multimillion dollar tech company 
  I'm speaking with right now -- they've said they are interested 
  in the work, hopefully they'll join and I can talk about them 
Eric Korb:  I've been working on vocabs
Brian Sletten:  I was planning on working on the Use Case 
  document this week.
Manu Sporny:  Eric has been working on the glossary.
Manu Sporny:  I need to resync docs.
Manu Sporny:  The last document, the Capabilities, kind of sprang 
  out of the detailed blog post, the credentials retrospective. One 
  of the things the W3C staff asked for was a list of capabilities 
  that an open credentials system should have. Because we hadn't 
  written that list down yet, we were able to chat with a few of 
  you offline and come up with that list. The credentials 
  retrospective post above in IRC has a list of goals for a 
  credentials ecosystem and a list of capabilities for that system.
Manu Sporny:  There are things like using an extensible data 
  model, ensuring that multiple market verticals can create their 
  own credentials without central coordination. Web-based PKI and 
  digital signatures. These are all capabilities we believe the 
  system should have. We analyze other existing technology matches 
  those capabilities or not.
Manu Sporny:  Quite a bit of work has gone into that and I think 
  that will be the first very rough draft of those things split out 
  by area.
Manu Sporny:  4 Bigs areas: Issuing, storing, managing lifecycle, 
  and consumption of credentials.
Eric Korb:  @Brian what doc file are you using? Happy to 
  contribute a few use cases.
Manu Sporny:  We've got features underneath that that we can get 
  from the blog post.
John Tibbetts:  I have one suggestion, about the blogs. I thought 
  the post on successes and failures was compelling. But I think 
  what's missing (but not from this document, this is about "what's 
  out there")... if there was a follow on document that says 
  "Here's how the technologies we're working on would deal with 
  this." A sentence or two about what parts of the technology would 
  address the capabilities and so forth would be good.
Manu Sporny:  I absolutely agree, but let me give you some 
  background. When I talked to the W3C staff members, and the best 
  way to address it is to say the problem exists, list the 
  problems, then go into all the things people are scared about 
  when talking about credentials, loss of privacy, lack of 
  anonymity, problem solved before, etc. Then talk about all of the 
  things that have been tried before and why they aren't an 
  acceptable solution ... and then leave it there. Don't talk about 
  the solution the CG has created yet because we need to first get 
  people on board that there is a problem and that we need a 
  solution. They've got products, etc. that need these things. Once 
  people are on the same page for the basic philosophy for what 
  we're trying to do. Then we can talk about how the proposal we 
  have, at least from the CG, addresses those capabilities.
Manu Sporny:  The W3C staff thought that getting into the CG's 
  solution too quickly that people would fixate on that and it 
  would detract from getting consensus on the high level vision and 
Manu Sporny:  I will try and write the CG solution blog post and 
  so folks like you can take that post and show it as a proposed 
Eric Korb:  Ek feedback on blog post: Do we need to distinguish 
  between identity and credentials? Is there one?
Manu Sporny:  Yes, there is a strong distinction that we make in 
  the technical work between identity and credentials. We've also 
  been trying to be very careful to not say that we're trying to 
  solve the identity problem on the Web because it's got huge 
  scope. We're just trying to talk about issuing, storing, 
  consuming credentials.
Eric Korb:  Concern that W3C sees it as the same
Manu Sporny:  Maybe we can try to make that more clear in the 
  blog post.
Manu Sporny:  We're going to have to try and make that point 
  clear to them.
Nate Otto: -1 To verifiable attributes
Manu Sporny:  They've also said they don't want to call it 
  "credentialing" and instead use "verifiable attributes" because 
  it's too generic but that's even more generic to me.
Matt Stone: -1 To "verifiable attributes" also
Manu Sporny:  We said we've been calling it credentials and we're 
  comfortable with it and these are the experts so we should call 
  it that.
Manu Sporny:  We were expecting the group to push back so that's 
  good, we're in line.
Brian Sletten: -1 To verifiable attributes and external names for 
  our topics of discussion :)
Eric Korb:  So, the login systems in the blog post, are they 
  identity or credential systems?
Manu Sporny:  Next topic will be talking about the capabilities 
  for the ecosystem and current proposal the CG is putting forward.
Matt Stone: Employer: "show me your credentials" -- not "what are 
  verifiable attributes"
Eric Korb:  In chart
Manu Sporny:  Login systems in the blog post are viewed by the 
  browser manufacturers as credentialing systems, some call them 
  light-weight identity systems. I think the credentials CG is the 
  only standards-related group that has a glossary and has gone 
  through the technical differences of specific systems on the Web 
  like persona, etc. and distinguished them from Mozilla Open 
  Badges and other credentialing systems, etc. In the blog post we 
  talk about anything that could be considered an 
  identity/credentialing system in order to case a pretty wide net 
  to catch things people might often bring up. For example, we're 
  talking about credentials and people might say "Oh that sounds 
  like Oauth" and we put that tech in the post even if that 
  technology isn't a good fit for the depth of the problem and what 
  we're trying to get to.

Topic: Credentialing Capabilities and Current Proposal

Manu Sporny:  We just want to make sure we address common things 
  that are brought up even if they don't fit.
John Tibbetts:  If we walk down the capability list and then say 
  a sentence or phrase for how our proposal addresses the issue.
John Tibbetts:  That would be good.
Matt Stone:  I'd like to know in addition to that, some level of 
  certainty that we know about this spec ... is it well understood 
  or do we have open issues that need to be solved, etc.
Manu Sporny:  So I'll do "What is our solution, how does it rate 
  on the scale, and how sure are we/what tweaks need to be made 
  with our solution?"
Manu Sporny:  The goals are meant to be fairly high-level, they 
  are from our vision statement.
Manu Sporny:  The distinction that we're making is that ... that 
  people have asked. ... what's the difference between a "goal" and 
  a "capability" and a "feature".
Manu Sporny:  Capabilities are things that the system should do. 
  When you're talking about a credentialing ecosystem, it should be 
  able to do these things, issue, store, manage credentials, etc.
Manu Sporny:  Features are not capabilities, it is just a talking 
  point around a piece of software. It's a thing a software product 
  has. Marketing folks can talk about those features. Today we're 
  just going over the capabilities. The things we want a 
  credentialing ecosystem to have. Keep in mind that this list may 
  not be complete and may need to be refined.
Manu Sporny:  As we go over the capabilities we'll talk through 
  them, refine them, and they'll eventually find their way into a 
  capabilities document.
Manu Sporny:  "Extensible Data Model" -- this has to do with 
  choosing a way of modeling the data that will allow arbitrary 
  statements to be made.
Manu Sporny:  This is a fundamental aspect of the W3C's Linked 
  Data/Semantic Web movement. There are open world and closed world 
  systems. The Web is an open world system; anyone can say anything 
  about anyone else. The fundamental data model for doing that at 
  W3C is called the Resource Description Framework (RDF), very 
  flexible, very will understood, under development for 15 years. 
  There are still fights over what the right solution for the Web 
  should be, academics vs. technical experts etc. XML tree model 
  vs. RDF vs. whatever.
Manu Sporny:  We've tried to get the right practitioners into our 
  camp and we're using RDF via a JSON-LD syntax. We have a number 
  of reasons why we're using that.
Manu Sporny:  Any organization or person should be able to make 
  any claims about any other org or person.
Manu Sporny:  "Choice of Syntax" - So the data model is an 
  abstract thing, concepts related to other concepts, this person 
  knows this person who is in the organization and they know 
  another person who has a high school transcript that has this 
  piece of information, etc. It doesn't say how we express it to a 
Brendan Benshoof:  The core of the issue here seem less in the 
  representation and more in how statements translate to a real 
  state of affairs in the world.
Manu Sporny:  So this is about syntax. Syntaxes come and go. 
  There's XML, then HTML, then JSON, then this then that. If we're 
  going to pick something that will be long lived then we should 
  decouple the syntax from the data model that expresses it. Today 
  we're going to pick JSON-LD to express the data model, but if it 
  goes out of favor by 2025, then the data model doesn't have to 
Manu Sporny:  There's a subject, predicate, and object ... in the 
  data model. "Jane likes cookies". Every language works like this. 
  RDF works like this; it's a very flexible data model. We're 
  making an assumption that JSON-LD is great today but it may go 
  out of favor in 10 years. We don't want our solution to fall 
  apart if the syntax goes out of favor. So we create this 
  separation to avoid that.
Manu Sporny:  "Decentralized Vocabularies" - A vocabulary is a 
  language that you use to describe something. The language that is 
  important to a Pharmacist or Medical board, is very different 
  from the language someone that is issuing a plumber's license of 
  an electronic transcript speaks. The terminology that they use is 
  very different. We shouldn't require those industry vertical to 
  come to a central place to agree on the language. They should be 
  able to develop their own language independently and innovate in 
  parallel. It enables market verticals to be able to come up with 
  their own solutions and talk about their industry how they want 
  to and not worry about how Google or IETF or whomever wants to 
  talk about their industry.
Manu Sporny:  So these vocabularies allow us to create this 
  architecture and then let the people who come up with the 
  credentials to decide the language that's important to them and 
  they don't have to coordinate with us. It may seem like it's 
  common sense, but if you look at, for example OpenID Connect 
  specs, it tells you exactly how you express X, Y, and Z. If 
  anyone in Finance wanted to start talking about insurance IDs, 
  KYC stuff, etc. they'd have to go to IETF and lobby them to have 
  it added to the vocabulary. The IETF should not be in control of 
  how the education, pharmaceutical, etc. verticals mark up their 
John Tibbetts:  All clear to me.
Brendan Benshoof: +1
Eric Korb:  Keep going! great to hear you speak
Nate Otto: +1 Decentralized vocabularies are great.
Manu Sporny:  Apologies if this is a firehose of information, but 
  it's taken us 4+ to get through all of this and it may take time 
  to sink in if it's new.
Matt Stone: +1 Decentralized vocabularies are essential
Manu Sporny:  It was so easy for us to integrate and interoperate 
  with mozilla open badges stuff because we've taken this open 
  world approach.
Manu Sporny:  This design approach is the reason for that.
Manu Sporny:  Web-based PKI. This might be a bit harder to grasp 
  for people who aren't familiar with security. I'll try to 
  explain. Most PKI systems, like those developed in 80's, 90's. 
  They require an X.509 certificate, if you've seen the pad lock on 
  your browser, etc. you're using this infrastructure. In the 
  beginning this infrastructure this was very secure; it was 
  difficult to issue "root" certificates for issuing these for 
  websites. But now the number of orgs issuing root certs has grown 
  to some 280 orgs/etc. The problem is that the US gov't can issue 
  certs for any org on the planet ... and so can China, India, 
  Pakistan. There are times when US and Chinese interests aren't 
  aligned (or whomever). So when you're inside China you get a 
  chinese certificate and they snoop all your traffic, etc. Nation 
  states do this all the time. The other problem with this system 
  is that there has to be a root of trust. In general, your 
  organization has to depend on some other organization for who you 
  can trust. So you have to trust both China and the US to use your 
  web browser in some circumstances which leads to problems. What 
  we're setting up doesn't require you to have this big list of 
  certificates in the same way; you can be picker with who you 
  trust. When you get a credential in this system, there will be 
  multiple signatures on it; one from the recipient, one from the 
  issuer, possibly ones from endorsers. The traditional way this 
  worked was that the system that was verifying the signatures 
  needed to have all of the certificates for all of the 
  organizations out there on your system already.
Manu Sporny:  And that meant that centralization was encouraged 
  so you just trusted some big players.
Manu Sporny:  Here the playing field is more level where you can 
  decide who to trust. All of the information you need to verify 
  the credential is in the credential or linked to it via the Web. 
  You can have small players claim keys and use them. And the 
  infrastructure is much more scalable as a result.
Matt Stone: I have a question on this topic
Manu Sporny:  This is important for scalability and a lot of the 
  OpenID Connect and JOSE specs dont' have this stuff. You have to 
  do key management and you can't do it on the fly with the Web.
Matt Stone:  If I'm a consumer, if I get a credential in, would I 
  see a list of signed by "company A, person B, endorser C" and 
  they might be any. And it's up to me to decide if I trust those 
Brendan Benshoof: +Q What are we doing to allow ease of use for 
  consumers interacting with the PKI?
Manu Sporny:  Yes, in general. A credential consumer that 
  receives the credential can decide who they want to trust. They 
  can push the responsibility off to another organization if they 
  want to or do it themselves. As a person receiving a credential, 
  all of this is kind of hidden from you. It's all machine to 
  machine communication that leverages all of this.
Matt Stone:  Let's say I'm a chief medical officer at a hospital 
  and I want to see that they are board certified. They send me a 
  certificate. It's signed by X, Y, and their medical school.
Brendan Benshoof: +Q How are we connecting Public-keys to 
  identities on the issuer's end??
Manu Sporny:  Yes. That's the idea. In the current technology 
  multiple signatures aren't implemented yet.
Dave Longley:  Is the question about multiple signatures, or is 
  it about who signed the credentials? [scribe assist by Manu 
Dave Longley:  The technology would do the verification of the 
  signatures, and tell you whether or not the signatures are valid 
  and were signed. You can figure out as a user, who did the 
  signatures and who signed it. [scribe assist by Manu Sporny]
Dave Longley:  You have a private part of the key, and a public 
  key and can push that out to the Web. [scribe assist by Manu 
Brendan Benshoof: This means a lot of companies/Industries who 
  previously did not employ security professionals in this context 
  will need to (or oursource)?
Dave Longley:  This has a lot to do with it being a web-based 
  system. [scribe assist by Manu Sporny]
Eric Korb:  Suggestion that we add - "multilingual" or does 
  JSON-LD do that natively?
Manu Sporny:  In the system that is being proposed here is more 
  flexible than the existing system and it allows you to do adhoc 
Manu Sporny:  Yes, JSON-LD does multilingual capability. The data 
  model is multilingual.
Manu Sporny:  You can express the name of a credential in every 
  language that has a BCP47 code in the credential itself.
Brendan Benshoof: +1 Multilingual (can we handle non-unicode 
  character encodings?)
Manu Sporny:  The credential can be viewed by someone in Japan or 
  France in their native language; same credential.
Nate Otto: That's a great capability.
Matt Stone: Is multilingual an attribute of RDF of JSON-LD or 
Matt Stone: +1 On multilingual
Manu Sporny:  "Choice of Storage" -- has to do with letting you 
  store your credential wherever you deep fit. At Google, Facebook, 
  a home server running at your house, in your watch, the recipient 
  controls it and no org can stop them from moving them around. It 
  has a strong analogy with phone number portability.
Nate Otto: Thanks, Manu
Matt Stone:  "Both" ... specifically, multilingual is an 
  attribute of the RDF data model and JSON-LD uses the RDF data 
Eric Korb:  +1 Manu overview
Eric Korb:  Just need link to use case docs
Nate Otto: See you all next week.
Received on Tuesday, 18 August 2015 14:49:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:39 UTC