The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back


Credentials CG Telecon

Minutes for 2015-03-31

Sunny Lee is scribing.

Topic: W3C Interest in Credentials WG

Manu Sporny: During last call, we said w3c wants to move fairly quickly, that timeline has been moved up even closer. very aggressive timeline. w3c wants web payment ig to recommend groups by end of june of this year. need to get everything ready by that time frame, meaning charter, exec summary etc.
Manu Sporny: Want new group created by sept of this year
Manu Sporny: Right now talking to w3c mgmt, trying to get things quickly set up
Manu Sporny: Lot of educating, staff contacts at w3c up to speed
Manu Sporny: Timeline: by june mgmt of w3c want a recommendation to create a wg. need to get all messaging cohesive. usually get 6 months, but we need to do this in 2 months. very aggresive timeline.
Manu Sporny: Need to have people on that list contacted by end of june.
Manu Sporny: Once that happens, they need to get caught up to speed on technical work.
Manu Sporny: By sept when we launch, we're all ready to go.
Manu Sporny: Problem with launching a wg like this is that we don't want to spin up a wg only to stall. that's the risk with taking on such an aggressive timeline.
Manu Sporny: When sept rolls around, people in the group should hit the ground running.
Manu Sporny: We basically have a month before w3c meeting in sapporo japan in late october 2015
Manu Sporny: To review the timeline again, we need to get as many orgs up to speed by june - july timeframe. need them to get caught up by sept, we only have several telecon meetings before gathering in sapporo
Manu Sporny: Questions?
Mark Leuba: Hi Manu, It was my understanding that the Roadmap would morph, with portions moving into the Executive Overview, the diagram moving into Use Cases and remainder (mostly schedule/timeline, issues, etc.) remaining - a part of which will it seems be duplicated in a charter? Is that the plan? Thanks, Mark
Brian Sletten: Can you tell us about what outreach work entails?
Manu Sporny: Reaching out to those in the recruiting doc.
Manu Sporny: Get them to understand everything that we're doing. bsletten you can definitely help out with that with current w3c members. effectively sending out an email and answering any questions they might have.
Manu Sporny: Any other qs with w3c credential cg update?
elf Pavlik: Where do we find info on steps for W3C members to support creation of Credentials WG ?
Manu Sporny: It is vital we execute on this stuff as soon as possible. If we screw this up, we'll have to wait another year. w3c is putting a lot of pressure on us.
Manu Sporny: Think we're gonna end up with actions to every single person this call. make sure they understand the work that we're trying to do.
Manu Sporny: In response to elf-pavlik the steps are what i just outlined. this is being done in a very different way. trying to fast track it. They're fast tracking it faster than we asked them to. We need to accelerate our timeline by a couple months.
Manu Sporny: Will know more after this week. Will be having discussion with w3c about nailing down a timeline.
elf Pavlik: How do they do official +1 ?
Manu Sporny: That link shows that our charter has already been integrated into the pitch
Manu Sporny: The official way this is done is you do a call for interest, you have a workshop, you create an interest group, after the interest group works for a year, you go into working group. We're skipping 18 months. Everyone on the working group is reading off the same page.
Manu Sporny: Next steps: everyone will be assigned orgs and we need to onboard those orgs
Manu Sporny: We give them a link to exec summary, we ask them specifically for a statement that they want the group to be created. Then we work with them to bring them up to speed. show them exec summary, use cases and some demos.

Topic: Executive Summary

Manu Sporny: This is a first pass at a one-pager executive summary.
Manu Sporny: Brief intro to what we mean by credentials, demonstrate that credentials are applicable to a variety of market places. outline group's goals, what we want to achieve.
Manu Sporny: How are we going to drive this? what steps do they need to go through?
Manu Sporny: We'll likely need to create a google doc form. we want to link them to the use cases so they can understand the type of problems we're trying to address.
Manu Sporny: Mark tried to reconfigure roadmap doc into this format
Manu Sporny: Any questions about exec summary or what we're doing there?
Manu Sporny: Would anyone have any concern about circulating this?
Brian Sletten: Will take a quick pass after the call but don't see any issue
Manu Sporny: Keep in mind this one pager is first contact for many orgs
Manu Sporny: Please comment on this and try to refine it
elf Pavlik: Can we replace all [LINK TO..] with links to current drafts?
Manu Sporny: Needs to be done by end of next week
Manu Sporny: Elf-pavlik yes idea is that this will be off of credential wiki. we'll create new wiki pages like we did for credential cg. use cases we'll put in cg respec format.
Manu Sporny: Use cases need to be in good shape by end of next week
Manu Sporny: We should talk about use cases.

Topic: Use Cases

Manu Sporny is scribing.
Sunny Lee: Based on the conversation last week - we felt pretty good wrt. what we've captured so far.
Sunny Lee: I took a look at it this morning, looking for additional comments - not sure if people have been able to make a pass at it.
Nate Otto: Maybe instead of "earning" as a phase, something along the lines of "recipient management"
Brian Sletten: I looked through it - looked at Web Payments Use Cases (micro use cases) - will look at it more this week.
Sunny Lee is scribing.
Sunny Lee: Who needs to coordinate on this? [scribe assist by Manu Sporny]
Manu Sporny: Let's send out an email manu, bsletten, SunnyLee NateOtto kerri will be on the thread
Manu Sporny: Because of the tight timeline we may step on each other's toes.
Manu Sporny: Have an idea of what this doc looks like in the micro use cases model.
Manu Sporny: If that model doensn't work, we can use what's there and shove it into an editor
Manu Sporny: NateOtto says he can't join via voice
Manu Sporny: Only on IRC

Topic: Credentials/Badges Vocabulary Update

Victoriano Giralt: Victoriano as well
Manu Sporny: Let's see if NateOtto can contribute on IRC
Nate Otto: Howdy
Nate Otto: Sure, can do my best
Nate Otto: At the Badge Alliance, we're getting ready to release the first Linked Data version of Open Badges
Nate Otto: The Credentials vocabulary draft that was shown a couple weeks ago hasn't changed since then; haven't seen any comments or feedback besides elf's, which was very helpful
Nate Otto: I proposed a badges context that referenced IRIs in the credentials vocabulary namespace, but was warned that it may be a long time before the credentials vocabulary is locked down
Manu Sporny: Here's the vocabulary document for OpenBadges http://specification.openbadges.org/credentials/#
Nate Otto: ... And so it would be better to use IRIs in a Badges vocabulary namespace
Nate Otto: So the question came up: Open Badges wishes to release a version that uses a Linked Data context in the near future. Some of the classes and properties in the draft Credentials Vocabulary could serve as the IRIs for components of badges that could appear in this context. But the Credentials vocabulary has not been thoroughly reviewed, and it might not be approved by this group or a future Working Group to be published for
Nate Otto: Some time. What would the consequences be of using IRIs within an Open Badges context for now that may later be superceded by terms in a published Credentials vocabulary. Is it hard to move from using one IRI for a term to another IRI?
Nate Otto: Manu and dlongley said it is more important that the _meaning_ of a term stays constant than the IRI that is its anchor
Nate Otto: So that's my #1 question this week, and I have 2 other minor ones
Nate Otto: What is the community's feeling on the terms included in the current draft of the Credentials Vocabulary? (too much, too little, just right?)
Nate Otto: And then consequences for the future: Should Open Badges and Credentials vocabularies look toward being merged in the future? If the community desires to move that direction, what legacy elements of badges would meet resistance?
elf Pavlik: IMO we may need make Open Badges 2.0 using Web Credentials directly but 1.x may need some extra compatibility layer
Dave Longley: First question: my opinoin about cred vocab should be aboslute bare min that enables interoperability
Dave Longley: Right now definedachievement and definedachievementassertions, don't think we need to talk about badges in core credential vocab.
Dave Longley: Don't think having it in this vocab is helpful. other than that, think everything else is fine
elf Pavlik: +1
Dave Longley: Need to define id credential and its core property
Dave Longley: Everything else that's domain specific whether badges or other kinds of credentiails should be pushed out to their own vocab
Manu Sporny: Rephrase: fundamentally there should be cred vocab and open badges vocab
Victoriano Giralt: +1 To "own vocab"
Nate Otto: Thanks for feedback, dlongley , manu, Victoriano
Manu Sporny: Openbadges should be specific to the open badges work. we want to do this because we don't want to slow down open badges work with all other stuff going on with web payments work
Manu Sporny: Cred vocab should be super generic and minimal so that open badges work or healthcare credentials data can be built on top of it
Manu Sporny: How best to achieve this from technical perpsecitve
Nate Otto: I do feel that achieving some of the use cases in the use cases doc depends on having defined achievements of some sort in scope. I don't necessarily have strong feelings about where vocabularies are built
Dlongley and manu feel like there's a way to enable work that doesn't block one another but in the end converges.
Manu Sporny: Think we have answers to all these questions.
Manu Sporny: Is it hard to move from using one IRI to another? as long as semantics don't change and you're using json-ld, not impossible but you really want to avoid doing this if you can
Nate Otto: Cool, thanks, all. Interested in elf-pavlik's thoughts, as he has spent some time looking into the technical implementation
Manu Sporny: You're relying on a json-ld trick from moving IRI to another
Gregg Kellogg: It can be down with owl:equivalentClass/Property as well, but best avoided
Manu Sporny: Rule of thumb, always use same IRI if we can do that, if we can't do that we need to sort it out
Dave Longley: If you start generating badges and you designate badge with some IRI, if you change the IRI, the meaning will change and the signature will not work
Dave Longley: Ideal situation is that all this stuff will converge and we will be using appropriate IRIs
Nate Otto: Manu, it sounds like the badges vocabulary should be built with terms that make sense for badges, and those can serve as the canonical IRIs for those terms.
Dave Longley: There will be some amount of pain if we put out a context with different set of IRIs and shift it over to something new
Nate Otto: Perhaps a converged vocabulary in the future could continue using IRIs in a OBI namespace?
Manu Sporny: Personally would rather put someting experimental in credential vocab and it effecitvely unchangeable, since open badges has been successful in using it. would much rather that happen and maybe stuck with term that's not fantastic, than us shiting and using a bunch of different IRIs
Manu Sporny: Nate is saying there are some terms we want to use in open badges vocab from cred vocab. Saying we should put something in credential vocab, eg claim, put that it in credential vocab and have that stick around in open badges v1.1, v2, etc, than the Badge alliance create a different claim property and use that for the nextn couple years and when open badges v2 come out use the credential vocab property.
Dave Longley: Recall NateOtto mentioned definedachievement. if we push all this out to topen badges, it makes things easier. Then there are minimal potential conflict.
elf Pavlik: I see benefit with focusing on modeling domain using Linked Data best practices first
elf Pavlik: So for example BA could model *Achievement*
Manu Sporny: I think we're in general agreement
elf Pavlik: And then use generic *Credential* as *AchievementCredential*
Manu Sporny: Eg badge alliance could model achievement
Manu Sporny: Do not agree with what elf-pavlik is saying, think it's backwards
Manu Sporny: Meaning credential is the base and a badge is a type of credential
Manu Sporny: Nevermind, I didn't understand what elf-pavlik was saying.
Dave Longley: Think he's saying modeling it the way you have in mind manu
elf Pavlik: BadgeAssertion == AchievementCredential
Dave Longley: Think the way elf-pavlik has written it out on gist was the way we had thought about designing it
elf Pavlik: While Badge == Achievement
Dave Longley: We may have multiple types; credentials and achievement might be a way to model it.
Victoriano Giralt: +1 Badge == Achievement BadgeAssertion == AchievementCredential
Dave Longley: You define whatever properties you want and define it inside a claim. You can create an achievement and it can be a type of badge.
Dave Longley: When you use json-ld framing you can merge it all together and use it in an application
elf Pavlik: We should also always check how things look with Merged Credentials Example
Manu Sporny: Need to catch up on the discussion and get caught up
Dave Longley: Believe the way elf-pavlik has modeled it matches linked data best practies
Manu Sporny: Question: is there a misalignment with what the Badge Alliance is doing with their badge stuff?
Dave Longley: Think this can work for them but NateOtto can probably speak to this.
elf Pavlik: Merged Credentials Example http://tinyurl.com/nu7lrvb
Nate Otto: Elf-pavlik is pretty close to what the BA has been doing
Kerri Lemoie: A bit out of the loop. Wouldn't mind having a followup call.
elf Pavlik: NateOtto, let's have small group call later this week!
Manu Sporny: Let's do that with elf-pavlik NateOtto kerri, manu dlongley
elf Pavlik: +1
Nate Otto: Inside what would be his `achievement` property (line 18) https://gist.github.com/elf-pavlik/029917ccc535e889f693/abb0de12f0a31eac4e679a229fb0413d5c5ab20e#file-definedachievementassertion-jsonld-L18 , the BA would have a 'recipient' property with information about the recipient identifier that was targeted by the issuer
Manu Sporny: The thing that's throwing us in the loop is that BA is tring to deploy now.
Manu Sporny: Don't want to get in the way of that.
Nate Otto: But if the recpient identifier is in fact the id of the claim, it would be duplicative
Nate Otto: So this is pretty close to where we might want to get to with v2
Kerri Lemoie: Do we want to get it out and appreciate you accommodating BA's needs.
Dave Longley: We don't want to hold up your work in anyway
Dave Longley: This is getting into the technical details that the working group would be getting into
Kerri Lemoie: No apologies needed. we really appreciate your work
Manu Sporny: 2 Other questions NateOtto had. scrolling back up.
Manu Sporny: What is community's feelings of the terms included in the draft? too much too little?
Manu Sporny: Assuming NateOtto means open badges vocab rather than credential vocab.
Nate Otto: I was talking about the credentials vocab draft
Gregg Kellogg: Definitely shouldn’t have name, description, image, issueDate, etc.
Nate Otto: Dlongley expressed a desire to pare it back to minimal set, dropping almost all properties besides `claim`
Dave Longley: Really credential vocab will only have like claim in it or something closely approaching that. something like claim, owner, recipient. you don't need much else for internoperatbilty, evidence or tag don't go into cred vocab. all this stuff goes into open badges vocab but not cred vocab.
Manu Sporny: Other thing is should open badges and cred vocabs merge in the future?
Nate Otto: Gkellogg, do you know of a preferred IRI for the issueDate term?
Manu Sporny: Believe current working thought is these are 2 different vocabs: cred is very minimal and only there to allow interoperabilty, open badges is much more specific to cater towards needs of the open badges community.
Manu Sporny: Don't think they should be merged but they should certainly complement each other
Dave Longley: What we want is that open badges badges are generic credentials
Gregg Kellogg: NateOtto, I’ll need to look, but I think something related to a schema:Event, or from more specific vocabulary might povide the same semantic meaning.
Nate Otto: Badges vocab/spec attempting to cater to needs of any community or group that makes use of defined achievements
Dave Longley: Generic cred vocab tells you how to define a claim. and open badges spec layers on top of it and goes into deeper property details.
Gregg Kellogg: Perhaps schema:startDate?
Nate Otto: Gkellogg, please post to mailing list in the next week if you can find something that you like. We're going to make a decision, and right now that's a term that is looking like it's in the badges vocab draft
elf Pavlik: Let's schedule after the call small vocab meeting later this week? awesome if gkellogg could join as well!
Gregg Kellogg: Sure, also dc:dateAccepted.
Manu Sporny: NateOtto is effetively saying that what elf-pavlik is proposing is what we want to do with version 2
Dave Longley: If we can sync up timeline of this working group with open badges version 2, then a lot of these problems can be resolved together.
Nate Otto: Hmm, interesting re: dc:dateAccepted & schema:startDate -- I'll look at them, feel that neither really captures the issuance of a credential meaning.
Manu Sporny: First off should be called open badges vocab not credential vocab.
Gregg Kellogg: +1, In the context, but not in the RDFS vocabulary definition
Nate Otto: I'm going to have to listen to audio of the call if possible to sort out this section. ;) sorry, I'm a bit lost.
Manu Sporny: Looking at sournce. NateOtto did the right thing. schema.org/name, restating what schema.org states
Mark Leuba: Great scribing Sunny, thanks! Hi Manu, It was my understanding that the Roadmap would morph, with portions moving into the Executive Overview, the diagram moving into Use Cases and remainder (mostly schedule/timeline, issues, etc.) remaining - a part of which will it seems be duplicated in a charter? Is that the plan? Thanks, Mark
Gregg Kellogg: This doc appears to be all the terms defined in the credentiails vocab, so the fact that name is something contextual, gets lost. we need to keep separate, from modeling perspective. we want to describe the properties that make sense in this context
Dave Longley: +1 To gkellogg
Gregg Kellogg: Keep separation of terms and think about what is part of the formal vocab.
Manu Sporny: 2 Things: 1 what's the formal vocab (minimal set of things that create interoperability), 2, documentaiton of the terms. we need to put out documents that talk about how badges or credentials are put together. open question is should we give examples in the vocab doc or should this be seprate
Gregg Kellogg: In csv group, we have metadat terms but doesn't also try to be formal vocab definition but rather references vocab definitoin. alll the terms and the way it's used is in one doc but context and vocab doc just tries to do that.

Topic: Roadmap

Mark Leuba: Where is the roadmap going?
Manu Sporny: Mark believe this is the plan. roadmap doc will disappear. since content is being split up among charter, executive summary etc.
Mark Leuba: Hi Manu, It was my understanding that the Roadmap would morph, with portions moving into the Executive Overview, the diagram moving into Use Cases and remainder (mostly schedule/timeline, issues, etc.) remaining - a part of which will it seems be duplicated in a charter? Is that the plan? Thanks, Mark
Mark Leuba: Sorry I cannot connect.
Manu Sporny: We need a roadmap to lay out a plan for the next 2 - 3 years. but wonder if that will end up reconstitute a lot of the content we already have.
Mark Leuba: Not a good idea imo.
Manu Sporny: Does anyone feel like the roadmap is a vital document? can we put it to the backburner?
Mark Leuba: Yes
Gregg Kellogg: Feels like it's useful for a transitory document. ultimately this will turn into some specification.
Gregg Kellogg: Point of roadmap is to help resolve direction of where we're intending to go. this eventually gets translated into specification text. Helps to focus disucssion but with an eye towards obscoleting it.
Manu Sporny: Let's wait to hear about Mark's argument on why we should keep roadmap doc.
Manu Sporny: Bsletten roadmap docs are not often used in w3c, effectively the charter for the group. once you have the charter then you retire it.
Mark Leuba: Manu
Nate Otto: I appreciate Mark's work on pushing these documents forward. :)
Manu Sporny: Roadmap helps people rally around the direction you're headed in. this is the direction we're headed in, these are the groups we're onboarding, this is what we need to do, etc.
Mark Leuba: I don't think we should keep it, but reform it to meet Greg's vision.
Dave Longley: In short, roadmap is very important for developing the charter
Nate Otto: (I like the combo or exec summary + charter, sounds like gkellogg has a good idea for how things fit together.)
Mark Leuba: Gotta go!
Manu Sporny: Will ping us about use case stuff