- From: <msporny@digitalbazaar.com>
- Date: Wed, 18 May 2016 09:36:27 -0400
- 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:54 UTC