W3C home > Mailing lists > Public > public-credentials@w3.org > May 2016

Verifiable Claims Telecon Minutes for 2016-05-17

From: <msporny@digitalbazaar.com>
Date: Wed, 18 May 2016 09:36:27 -0400
Message-Id: <1463578587720.0.2034@zoe>
To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Brian Sletten for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:

http://w3c.github.io/vctf/meetings/2016-05-17/

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

----------------------------------------------------------------
Verifiable Claims Telecon Minutes for 2016-05-17

Agenda:
  https://lists.w3.org/Archives/Public/public-webpayments-ig/2016May/0018.html
Topics:
  1. Introduction to Alka Gupta from GlobalID
  2. Blockchain and Identity 
  3. Verifiable Claims Data Model Specification
  4. Credentials Transparency Initiative Terminology
  5. Target Date Web Payments IG Hand-off
Resolutions:
  1. Augment the "Credential" terminology in the specification 
    with a modifier like "OpenCredential" or "IdentityCredential" or 
    "VerifiableCredential".
Organizer:
  Manu Sporny
Scribe:
  Brian Sletten
Present:
  Brian Sletten, Alka Gupta, Manu Sporny, Nate Otto, Shane 
  McCarron, Dan Burnett, Eric Korb, Dave Longley, Stuart Sutton, 
  Matt Stone, Richard Varn, Rob Trainer, Todd Albers, Les Chasen, 
  Colleen Kennedy, Jason Weaver, David Ezell
Audio:
  http://w3c.github.io/vctf/meetings/2016-05-17/audio.ogg

Brian Sletten is scribing.

Topic: Introduction to Alka Gupta from GlobalID

Alka Gupta:  Hi, Alka Gupta from GlobalID. I think Greg Kidd 
  introduced what we do a while ago. This is my first call, happy 
  to be here and see where the group is wrt. progress.

Topic: Blockchain and Identity 

Manu Sporny:  We're going to move the agenda around a bit to 
  dovetail things together. We're going to start with Blockchain.
Manu Sporny:  A number of us are still trying to get cleared to 
  discuss this publicly, but in general, we are inviting a number 
  of organizations involved in blockchain and identity and 
  credentials to present in 30 min chunks over the next two months.
Manu Sporny: 
  https://github.com/WebOfTrustInfo/ID2020DesignWorkshop
Manu Sporny:  The primary purpose is to get some cohesion around 
  identity and blockchain as it applies to verifiable claims. We 
  might get some ID2020 discussion. How do you make sure someone is 
  control of their data? What are the technical solutions? We're 
  not reliant upon blockchain but we think there a number of 
  technologies that could be useful to us in the world of 
  verifiable claims.
Manu Sporny:  Any questions about this?
Nate Otto: Is there any orgs you can announce that will be 
  participating in these presentations?
Manu Sporny:  ID2020 is being host by the United Nations to have 
  pilots running by 2020 and have the under identified have 
  credentials by 2030. A number of the verifiable claims folks are 
  going to be participating to help define what the architecture 
  looks like. We'll be publishing papers and discussions 
  afterwards.
Shane McCarron:  I know the W3C is holding a blockchain workshop 
  going on and I was wondering if there is cross-pollination going 
  on.
Manu Sporny:  Yes, there is. Several of these people are 
  submitting position papers. The W3C is looking at non-financial 
  industry use cases. Clearly there are financial industry uses 
  case, but they want to discuss others.

Topic: Verifiable Claims Data Model Specification

Dan Burnett: Data Model doc:  
  http://opencreds.org/specs/source/claims-data-model/
Dan Burnett:  I've put a link for the document. This is document 
  is a reverse engineering of some concrete examples that the 
  Credentials Community Group created. We've supported JSON, 
  JSON-LD and WebIDL. We've tried to capture that data model and 
  show how it can be represented in different serializations.
Manu Sporny: We're talking about section 4.1.2 now - Expressing 
  Claims in JSON
Manu Sporny: Now we're moving to section 3.3
Dan Burnett:  The spec talks about expressing basic claims in 
  section 4.1.2 - that's the simplest example. I've been working 
  from examples for most of this. So, let me know if I got 
  something wrong. The other change is moving the word credential 
  back into the document. I also mention identity, it's going to be 
  hard to get away from that. Any comments on the spec so far?
Manu Sporny:  Thank you for working on this Dan. It's a great 
  direction. At some point, we're going to have to tell the WPIG we 
  are ready to take a voting package to the W3C membership for a 
  vote. What should we focus on for the next month to do that? 
  Where are we with the spec now? Can we hand it over to a WG? Of 
  not, what should we focus on to get there?
Dan Burnett:  There is a bunch of linking/editorial cleanup that 
  I'll be doing. It needs and introduction and abstract. I plan to 
  write a first draft of that so people can review. It's important 
  for people to look at the data model and how it is going to be 
  expressed in those formats. We need to make sure there is nothing 
  missing or wrong.
Manu Sporny:  Thank you, Dan.
Manu Sporny:  It's worth mentioning that the content in this 
  document is something that we should have agreement on in the CG 
  and VCTF. We are agreeing on that this is what things should look 
  like. The best thing that could come out of this is a bunch of 
  large organizations saying this is the best way to proceed. That 
  they would be willing to deploy it to there customers.
Manu Sporny:  If you are on this call and are from a large 
  organization, let us know what you think, especially if you 
  disagree with the direction we are taking we. We do not want that 
  to come out later. We want to address the issues upfront.
Dan Burnett:  One other thing I did want to bring up. This 
  document does talk about identities (something we said we weren't 
  going to talk about). The reason it is in there is because the 
  credentials/claims dataset makes reference to that. Should that 
  stay in? Should the identity pieces be moved? I don't have a 
  strong opinion on but I suspect others will.
Nate Otto:  My question is on expressing claims in JSON vs 
  JSON-LD. What is the benefit we see for expressing this in 
  regular old JSON?
Eric Korb: @Burn typo "4.2.2 Expressing Claims in JSON-HD" should 
  be "JSON-LD"
Dan Burnett: @Erkorb thanks
Manu Sporny:  What is the value of plain JSON claims and how do 
  you do signatures on that. In the survey feedback we put out, 
  there was one large telecom company interested in self-claims 
  that doesn't need digital signatures. If the model is flexible 
  enough to do self-claims (things you type into a form), they had 
  use cases that worked with self claims. The value is dependent 
  upon the use cases.
Nate Otto:  And a second question: How do you perform a 
  LinkedDataSignature2015 on plain JSON data? [scribe assist by 
  Nate Otto]
Dan Burnett: @Erkorb unless we want to move to Hi-Def JSON . . . 
  (joking)
Eric Korb: Burn, +1 ;-)
Manu Sporny:  That's where it came from. It also came from we 
  have LinkedData Signature stuff and that stuff is controversial 
  in the crypto community. There is a subset that thinks we should 
  use JOSE (JWS, JWT, etc.) If people want to do that, they can. 
  More recently we have changed the LInkedSignature specs to allow 
  the use of JWT-based signatures. They are ugly and nasty, but our 
  hope is to stave off some of the arguments against the VC work 
  because we are saying
Manu Sporny:  LinkedData signatures are a nice way to represent 
  them.
Manu Sporny:  We're not picking a winner.
Dan Burnett:  The definition for an "id" for an Identity should 
  indicate that the identifier doesn't have to be long-lived, but 
  can be (want to be clear that the data model supports both 
  long-lasting IDs and ephemeral ones ... so varying levels of 
  privacy and limited disclosure implications) [scribe assist by 
  Dave Longley]
Nate Otto: Interesting to hear manu say that the 
  LinkedDataSignature2015 spec can be flexible enough to use JWT as 
  well as the core linked data signature method. I agree that would 
  look pretty ugly, but that is an interesting avenue to keep this 
  work open to.
Dan Burnett: @Dlongley okay, will add that.  Feel free to submit 
  a PR with precise text if you have it, but if not I'll write it
Manu Sporny:  The other question was how to transfer that into a 
  LinkedData signature. You suggested adding a context and that is 
  spot-on and then you can take a signature. We're thinking about a 
  new signature mechanism around JOSE/JWT. If some of the IETF 
  people or others will assist, then we will support it. If it 
  doesn't happen, we'll only have JSON-LD and LinkedData 
  signatures.
Dan Burnett:  Yeah don't have anything precise :/ [scribe assist 
  by Dave Longley]
Nate Otto:  I think it is important to keep this open to people 
  who don't want to use JSON-LD.
Dan Burnett:  This is the second question we got about this. 
  These examples that we show are just examples, not normative. We 
  currently show a signature mechanism with regular JSON. Can we 
  show something else?
Nate Otto: +1 To showing an example of the simplest claim 
  possible wrapped in JWT.
Manu Sporny:  That format doesn't exist yet. We have some ideas 
  but don't want people to reject them outright because we haven't 
  thought it through. We can show the non-Base64-encoded version 
  and that would be a good compromise.
Dan Burnett:  I would welcome an example from someone.
Nate Otto: Yes, it'll be ugly in the document, (with 
  base64decoded version as well), but that might help people 
  understand why we want to use the LinkedDataSignature2015 
  instead. ;)
Manu Sporny: https://web-payments.org/specs/source/ld-signatures/
Manu Sporny: http://json-ld.org/playground/
Nate Otto: Awesome! Thanks for adding the signed tab to the 
  playground!
Manu Sporny:  The LD Signatures spec has more complete examples 
  of what a LD Signature looks like. If you go to the JSON-LD 
  playground, it has support for signatures. You can copy and paste 
  from the signature tab.
Eric Korb: NateOtto, +1 good for comparison
Dan Burnett:  That's probably less controversial than plain JSON 
  with a LD Signature.
Manu Sporny:  We should definitely demonstrate both signature 
  mechanisms in the spec and be real examples of what we expect 
  them to look like.
Manu Sporny:  Any other questions on the specification?

Topic: Credentials Transparency Initiative Terminology

Manu Sporny:  This came about after a few of us took a look at 
  the CTI vocabulary. We were trying to take the CTI work and 
  express their credentials using the VC data model. What we hit 
  was a terminology and modeling issue. The way that the CTI uses 
  the term credential is slightly different to the way we use in 
  the CG.
Manu Sporny:  We think that there might be a pattern emerging 
  (banking, healthcare, education) use the term credential in 
  slightly different ways. The question is, should we stay away 
  from the term 'credential' and let people use it the way they 
  mean it or should we take on the work of aligning the meanings 
  across these industries.
Manu Sporny:  If we don't use it, different verticals can use it. 
  The pro is that verticals figure it out themselves. The con is 
  that there will inevitably be two market verticals that use the 
  term in contradictory ways.
Dave Longley: It would be good if the core, generic format for 
  verifiable claims had a clear use of the term Credential (or a 
  replacement term or set of guidelines) going forward.
Manu Sporny:  If we establish our meaning and discourage reuse in 
  the market vertical, at least there is one group trying to 
  shepherd the term through in the use on the Web? The downside is 
  that we won't talk with one of the verticals or they'll just do 
  their own thing.
Nate Otto: Could you highlight what the two definitions are and 
  what their conflict is in more detail?
Manu Sporny:  We think this is going to continue to happen. 
  Should we stop using the term or should we encourage the CTI to 
  stop using it. Or is there some middle ground?
Dan Burnett: Dlongley, right now the core doc says that 
  Credential is just the name for the container.  Are you saying 
  that is not clear?  I think it may be less than we want to say, 
  but I don't believe it is unclear as written.
Stuart Sutton:  I think you paint the picture correctly. I think 
  you paint the picture of variation in multiple verticals 
  correctly as well. I think that trying to get the verticals to 
  define the term in the same way may be a fool's errand. The 
  amount of pushback that the CTI group is getting to not calling 
  it a credential is significant.
Stuart Sutton:  There is murkiness around what is meant. It is 
  used to describe the thing that describes the substance of the 
  credential. The thing that someone holds is also a credential. 
  There are relationships between the claim and people are also 
  called a credential.
Dan Burnett:  I don't think it's unclear, i'm just speaking to 
  difference in definitions for "Credential" w/CTI and potentially 
  other groups (saying we should define it and tell people how to 
  use it with verifiable claims) [scribe assist by Dave Longley]
Stuart Sutton:  If we look at organizations that span these 
  groups, they have a lot invested in their literature and how they 
  use the term.
Stuart Sutton:  I think the problem with VCTF putting a stake in 
  the ground is that it narrows the definition to a set of claims. 
  Credentials exist independent of claims. That is where the 
  pushback from the credentialing community comes from.
Dave Longley:  To speak to the idea of credential requiring 
  claims to exist. Looking at the CTI work, we took it from the 
  other direction thinking claims were out of scope. The VCTF takes 
  the position that you have something that is tied to you. The CTI 
  talks about more abstract things like types of degrees. A 
  personal holding on to the degree doesn't hold the abstract 
  thing. It is more like a certificate.
Dave Longley: 
  https://docs.google.com/document/d/1lKBhagznl4THYQ-Tth8NXXNae5g2XC7S0iEbnPscvmg/edit?usp=sharing
Dave Longley:  That's some of the struggle we've had about using 
  the CTI terms in the VCTF work.
Nate Otto: From the badges space, we find that the term 
  "credential" is already very overloaded, and it will be difficult 
  to try to carve out a space for our usage in those overlapping 
  conversations. I like the term, but it is already used in all the 
  ways described and organizations have deep investment in using it 
  as a generic term. There's a big conversation on "are all badges 
  credentials? can all credentials be expressed as badges?" Many 
  different education
Nate Otto: Providers and assessors are picking their own names 
  for what the artifact that they're delivering is 
  (microcredentials, nanodegrees, badges). Use of "credentials" is 
  very common. I think either we operate in this overloaded space 
  (which is possible) or we avoid it by picking a different term.
Dave Longley:  Please look at this Google Doc that discusses some 
  of the issues.
Dave Longley:  CTI talks about certificate type in the abstract 
  (MBA). In the VCTF work, we're talking about actually getting a 
  credential indicating that you've earned a certificate of this 
  type.
Eric Korb:  I echo what Dave has said (we've been collaborating). 
  I'm supportive of the CTI work and the VCTF work. It works to 
  connect them. I support the using the term Credential as a class.
Matt Stone: -1 Certificate
Manu Sporny:  Some communities use the term in the abstract sense 
  (CTI) others use it in the concrete sense (VCTF). There are a 
  couple ways out of this. We have no ability to change what the 
  CTI is doing. One option is no change. We use the term 
  credential. We have a strong definition. We don't change and 
  figure out how to model the CTI work. Option two is change the 
  use 'ClaimSet' which is awkward. Or we use the term 'certificate' 
  for the concrete holding and [CUT]
Nate Otto: -0.5 Certificate
Manu Sporny:  Remains more abstract.
Dave Longley: To be clear we would map the CTI "Credential" to 
  "CertificateType" in our VCTF JSON-LD context
Shane McCarron: +1 To bagel
Matt Stone: +1 To sharing bagels
Richard Varn:  We're not going to solve this issue. Certificate 
  isn't going go down well with the education space. We're building 
  a standard that will be implemented. We're giving name to those 
  things that will be supported by the standard.
Dave Longley: "IdentityCredential" is another thing we've 
  discussed, has both advantages and disadvantages.
Nate Otto: What RichardVarn is describing is essentially the 
  approach taken by Open Badges vs the broader generic term 
  "digital badge"
Shane McCarron: VCredential... not terrible
Richard Varn:  If we use an augmented form of the term (e.g. 
  vCredential) we can indicate specifically one of our terms.
Manu Sporny:  That is helpful and I can see how it might work.
Nate Otto: +1 To something like "OpenCredential", "vCredential", 
  "IdentityCredential"
Manu Sporny: I like the augmented Credential as well...
Matt Stone:  It is folly for us to overthink what a professional 
  or enduser might use to make their statements. They'll use the 
  language of the vertical they are in (degrees or board 
  certification or resume or cv). It's irrelevant to us what they 
  are going to say about their individual verticals.
Brian Sletten:  What about iCredential? *ducks*
Dan Burnett: WebCredential
Stuart Sutton: +1 VCredential
Dave Longley: I agree that we shouldn't focus on the end user, 
  just want something that makes sense to the community
Manu Sporny:  We're seeing support for modifying the term.
Manu Sporny: We have consensus around NOT using the word 
  certificate! :P
Dave Longley: We're already using "IdentityCredential" in some 
  prototypes we've built that use the Credential Management API
Stuart Sutton:  As a member of this group, I support a modified 
  term and avoid a common term like Certificate.
Dan Burnett: I would avoid "vCredential" because some of them 
  will not be verifiable, and it may be confusing to talk about 
  vCredentials and Verifiable vCredentials.  Maybe something like 
  "web credential"?
Manu Sporny:  I think this modified form would address CTI's 
  concerns with the use of that term.
Dan Burnett: I am happy to change it to "X Credential" until we 
  figure out what we want X to be.
Eric Korb: VerifiableCredential

PROPOSAL:  Augment the "Credential" terminology in the 
  specification with a modifier like "OpenCredential" or 
  "IdentityCredential" or "VerifiableCredential".

Brian Sletten: +1
Nate Otto: +1
Manu Sporny: +1
Dave Longley: +1
Shane McCarron: +1
Dan Burnett: No, NOT VerifiableCredential
Dan Burnett: +1 Proposal
Dave Longley: +1 To burn
Stuart Sutton: +1
Eric Korb: +1
Shane McCarron: I like "vCredential (tm)"

RESOLUTION: Augment the "Credential" terminology in the 
  specification with a modifier like "OpenCredential" or 
  "IdentityCredential" or "VerifiableCredential".

Stuart Sutton: +1 To burn
Eric Korb: Burn, okay "bagel" then, grins.
Matt Stone: -1 Verifiable - it excludes self asserted claims
Nate Otto: Good chat, all. ;)

Topic: Target Date Web Payments IG Hand-off

Dan Burnett: Shane and erkorb, see my reasoning a few lines above 
  as to why v or Verifiable as prefix is problematic in the text of 
  the document.
Shane McCarron: Burn thanks - I had missed that
Manu Sporny:  We'll figure out what the modifier is later. We 
  should have a voting package for the WPIG before the meet at the 
  end of June. That gives us a month and a half. It's doable, but 
  we need to make better progress.
Eric Korb: +1 Great call
Matt Stone: Thanks everyone
Received on Wednesday, 18 May 2016 13:36:52 UTC

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