Credentials Community Group Telecon

Minutes for 2014-09-09

Agenda
http://lists.w3.org/Archives/Public/public-credentials/2014Sep/0000.html
Topics
  1. Introduction of new Members
  2. Quick IGF 2014 Review
  3. Badge Alliance and JSON-LD Discussion
  4. Charter Vote Status
  5. Use Case Review
Organizer
Manu Sporny
Scribe
Dave Longley
Present
Dave Longley, Manu Sporny, Evgeny Vinogradov, Mary Bold, Tim Holborn, Bailey Reutzel, Chris McAvoy, Mark Leuba, Bill Gebert, David I. Lehn
Audio Log
Dave Longley is scribing.
Manu describes today's agenda.
Manu Sporny: Chris if you could give us a quick rundown of the JSON-LD discussions happening at Badge Alliance at some point during the call, that would be great.
Manu Sporny: Any other changes to the Agenda?
No changes requested.

Topic: Introduction of new Members

Evgeny Vinogradov: I'm from Yandex, largest search engine in Russia along with one of their largest e-commerce platform providers. I'm from their payments and identity team there. I have been participating in Web Payments Community Group for a while now and look forward to participating in the Credentials Community Group as well.

Topic: Quick IGF 2014 Review

Manu Sporny: We ran a workshop on credentials and payments at this year's IGF: https://igf2014.sched.org/event/781846f97d253b11129ee88f4dd176ff
Manu Sporny: Last week we met in Istanbul, Turkey with th global community, at IGF put on by UN, the point is to get policy makers, legal teams, govt officials, technologies together under the same roof to discuss issues, human rights issues, pervasive monitoring, getting next 3 billion people connected to the Web, mainly from a policy/framework standpoint not from technology.
Manu Sporny: Mary bold, Pindar wong, and I held a workshop along with jeremy malcom from Electronic Frontier Foundation Louise Bennett from BCS, and Norbert Bollow from Civil Society held a workshop there to get international community to chime in on the technology we're creating here specifically related to payment but also to get credentials integrated into the core of the Web.
Manu Sporny: I think it went really really well, we were doing something pretty experimental, typically you have a group of 5-6 panelists talk for 60 minutes then 3 or so questions and audience experts don't get to participate etc. We changed things up to minimize the panelist talking and the rest of the time was getting audience involved to get feedback, find out what they thought about the credentialing work and what we've been doing in the payments group for the past couple of years as well as things like the badge alliance work and things in general for the Web. We were concerned that we wouldn't get engagement from the audience but that wasn't a problem at all, the audience really engaged, had great input for 90 minutes, etc.
Manu Sporny: Questions about how govts use creds tech, how this affects pervasive monitoring, etc
Manu Sporny: Almost everyone in the room said they wanted to be involved in the work we're doing here
Manu Sporny: So a really great outcome.
Manu Sporny: Even better, the entire session was video recorded and is now up on YouTube: IGF Payment, Privacy, Policing Paradox workshop video: https://www.youtube.com/watch?v=m8cIYzy5MIA
Manu Sporny: 1Hr 15min long it's really interesting -- will bring you up to speed on how everything we're working on is meant to work
Manu Sporny: There's an after review/workshop report we're putting together now
Manu Sporny: We'll feed that input into the W3C Technical Plenary
Manu Sporny: Lots of people care about this around the world, we think W3C should create an official standards track tech group to take this work on.
Manu Sporny: Mary any additions?
Mary Bold: There were more than 40 people in the room, they were active. Manu and Pindar they had a very inventive presentation style. They said we weren't going to do talking heads at a panel, and they got people understanding payments, and i don't think anyone in that room felt that it was being dumbed down for them. They appreciated the steps being taken, imagining the information moving across the web from browser to website, etc. I don't think anyone took it as being super pedantic, and they took it as a good live action explanation. I think that helped make the audience engaged and the first question came in at like 10 minutes or something, it was lively presentation, questions ranged from technical down to tell me where the money is.
Mary Bold: I think it did its job and people will be coming back to learn more.
Manu Sporny: Any questions about IGF or what we'll do to follow up?
Manu Sporny: Or general questions about why we did it in the first place?
Tim Holborn: Do you have any strategy in place to maintain contacts?
Manu Sporny: We have a list of email addresses, we'll be sending them information about how to join the creds CG and how to participate in the work and we told them we'll give them quarterly updates on the work in this group
Manu Sporny: Same strategy we've been following with the Web Payments CG
Manu Sporny: We send out every quarter things they might be interested in, for example, votes that they might want to participate in
Manu Sporny: So invitations to join the group and information about what's going on will be going out in email
Tim Holborn: I'm finding extraordinary interest in the education sector, for creds, some of that interest may come from those that are not technically savvy but not participating in the group.
Tim Holborn: It's really encouraging to get the feedback
Manu Sporny: We have a fairly broad group of interest here, people interested in govt ID, educational creds, finance and know your customer info, trying to pull all those people into the same conversation is always going to be a challenge
Manu Sporny: Anyone with ideas about how to engage in all of these groups would be welcome
Manu Sporny: Anything else on IGF before we move forward?
Bailey Reutzel: The video you're talking about is also the one on youtube?
Manu Sporny: Yes
Manu Sporny: Unfortunately they didn't start recording until 10 minutes in, so we missed some intros but we actually prerecorded those so you don't miss anything if you watch this first: https://www.youtube.com/watch?v=OSCIicSi1ks&list=PLmwV_GNAvYmA4Qtssit6_U5AgLGYodxtI
Manu Sporny: Anything else?

Topic: Badge Alliance and JSON-LD Discussion

Manu Sporny: Last week the badge alliance had a discussion about the use of JSON-LD for the open badges work. Chris could you give us a quick rundown on that discussion and where you think the BA community is on the use of JSON-LD?
Chris McAvoy: Notes for BA meeting on JSON-LD in the standard http://etherpad.badgealliance.org/ba-standard-sept2
Chris McAvoy: To give background, i think probably everyone on the call knows about the BA, but the open badges project is targeted at mostly education, we incubated at Mozilla, we are working on a standard for verifying badges and sending them around, etc.
Chris McAvoy: The community is pretty vibrant, lots of people working with the open badges standards, BA was born/run out of Mozilla. We have groups working on different aspects of badging, the group i chair is continuing to work on the issuing badges standard. Manu and Accreditrust have been involved for a long time and we've spent a lot of time with Manu more recently talking about adding JSON-LD to the specification to make it more robust and flexible and give us options for things like digital signatures.
Chris McAvoy: And to enable the idea of adding extensions to the spec, like adding location or domain-specific things, JSON-LD has that ability
Chris McAvoy: So that brought us to it (JSON-LD) initially, the last couple of weeks we've been discussing it in the standards working group and other groups inside the alliance are sold on JSON-LD. Where we're concerned, like Tim's point, is that we have an education focused community and in a lot of cases they aren't technical, and some of the process we have today even confuses some in the community, so adding complexity is concerning, a lot of the discussion we had in the last week is about that. We've been selling the idea of using JSON-LD and back filling with tools and how to use it, etc.
Chris McAvoy: I feel like we have a good tentative plan, it won't be instantaneous it will be a process to move the community over to using JSON-LD to describe badges
Manu Sporny: Is there anything we can do, i apologize that i haven't been able to join more in that discussion, but hopefully we'll have some breathing room over the next month, is there anything we can focus on to help you sell the technology within the BA, would it help to mark up a badge, or would it help to link to the videos or do some kind of tutorial, if we could only do one thing what should that thing be to help you sell this internally?
Chris McAvoy: It's actually not selling it internally at this point, it's the broader community, and i think that will just take time, we need resources so i'll take you up on that, for some of the discussions we're starting on the mailing list, etc. We need to target a few issuers of badges to get them to adopt the new standard that hasn't been written/formalized yet
Chris McAvoy: We have some members in the community that i'd like to start working with to get them to experiment with JSON-LD because the move to JSON-LD will open up the idea of endorsement of badges and extensions. That could be the killer app that gets people to understand where we're headed with this spec/standard.
Chris McAvoy: If there's one thing you could do it would be if you could be available to be the go-to hand-holding expert on the standard and help a few key players get over any technical hurdles
Chris McAvoy: And so far you've been doing that so we're in good shape
Manu Sporny: So one point here is that Dave Longley is here on the call one of the creators of JSON-LD and Dave Lehn is here as well and they know as much or more than I do about JSON-LD so you can talk to them as well
Manu Sporny: We could do a call to get any the concerns you've got worked out and we could try and get the questions you have worked out in 15-30 minutes
Chris McAvoy: I appreciate it, thank you
Manu Sporny: Is there a timeline you're thinking or are you just thinking it will take a couple of months and you'll do the best we can, etc. blog posts responding to questions, etc.
Chris McAvoy: Yeah the latter but i do think we need more of a plan ... put khaki pants on it, get it shipped.
Tim Holborn: I'm looking at an application trying to promote physical activity if there's something that would be mutually beneficial that would be great

Topic: Charter Vote Status

Manu Sporny: Here's the current charter proposal: http://www.w3.org/community/credentials/charter/
Manu Sporny: We have a charter that's been voted on currently.
Manu Sporny: Tim, you had mentioned on the mailing list a number of changes you'd like to see in the charter, we had a quick discussion offline about it, they are certainly things we should consider and I personally agree with but we are mid-vote and we don't want to invalid the voting process and it would take another month to make the changes and get everyone to read it and hold another vote and given our time crunch for having something in time for W3C TPAC, I feel that we should postpone the changes until we have /a/ optional charter.
Manu Sporny: I think we should propose tim's changes in parallel with everything else we're doing later
Manu Sporny: And we can start voting on use cases and things of that nature
Manu Sporny: Tim, thoughts?
Manu Sporny: Vote link is here: http://doodle.com/cdcnge9qzwfhbamn
Tim Holborn: I'm not familiar with w3c process and i can appreciate some of the technical things you're talking about.
Manu Sporny: Typically people vote right away ... and then most vote within 24 hours of the vote closing
Manu Sporny: I'll send a ping out to the mailing list to remind people to vote before this Friday.
Manu Sporny: When the vote closes at the end of this Friday.
Manu Sporny: Any other questions about Tim's suggested modifications?
No other questions raised.
Chris McAvoy: Is there a link to the proposed changes?
Tim Holborn: I didn't edit the one online, i just grabbed it and put into google and posted the link to the list
Manu Sporny: Could you summarize the changes really quickly?
Tim Holborn: The first bit is about a technology instrument (aka contract) that verifies something, privacy and security and whether it can be entirely secure, data security is also a concern, with respect to the ODRL community i put that in there as well. So I share this credential for the purpose of you sending me a product, and nothing else. How do I enforce that my data isn't going to be misused.
Tim Holborn: As I added WebID as a dependency or liaison, WebID has a vibrant community associated through FOAF with support through persona, although the concept of persona and creds are very separate they both know about each other - at least that was something that was worth involving them in the group, from what i'm aware Manu has actually started that conversation.
Manu Sporny: So the ability for having your data taken from you and sold when you didn't mean it to be sold - so having a way to express that this credential is only for some specific purpose and can't be used for another reason
Tim Holborn: I thought this might provide some additional safeguards around it, so the fact that it's a digital instrument so like a contact, the signature is a legal instrument that's one of the technology things that we should look at.
Tim Holborn: Any comments or feedback?
Manu Sporny: Personally, I think it's a good idea, (personal not company position) the ODRL community has been working on this mechanism to specify rights for when you transmit data.
Manu Sporny: They've been working on that problem for quite a while and we should be able to reuse what they've developed over the last 3-4 years, the problem is no one has done a technical implementation to make sure it works
Manu Sporny: From what i understand i don't think that BA or the IC stuff has yet discussed a way to say you can only use this information for these purposes
Manu Sporny: It's important to be able to express what your rights should be

Topic: Use Case Review

Manu Sporny: The web payments community group is entirely dependent on the output of this group as far as credentials are concerned, and the hope is that this group will take these use cases from the that group very seriously
Tim Holborn: +1
Manu Sporny: We're going to read through these, not really pause to discuss, but then we'll go back and talk about the ones that are of concern to those in this group
Dave Longley: +1
People on the call seem to be okay with this approach.
Manu Sporny: We have a glossary above that will have to change because it was pretty specific to the web payments group
Manu Sporny: And we'll have to modify that slightly. Ok, here we go...
USE CASE: Store basic credentials and payment provider information on the Web in a way that is easy to share with various payees/merchants given authorization by the owner (payee) of the credential, and that is easy to synchronize between devices.
Manu Sporny: You should be able to store a piece of information and transmit it to who you want and that should only happen when you authorize it
Tim Holborn: What would the authorizer be called
Tim Holborn: It would be an educational institution? or would it be a govt department for a passport ... maybe a payment provider?
Manu Sporny: We would strike 'and payment provider' and replace it with examples like educational provider, gov't passport, etc
USE CASE: Steve (buyer) visits a website (merchant) and authorizes the transmission of one or more credentials (such as proof-of-age, shipping address, etc.) previously stored with a credential storage service to the website to enable access or fulfillment of a transaction.
Manu Sporny: This has to do with someone providing a credential to a website to let them get through a gate on the website to let them do something, and here the website can't just trust the person they need to trust a 3rd party, for example, if someone needs to shut down a nuclear reactor remotely you'd have to provide a number of high stakes credentials .... that's pretty extreme example and one we should avoid in the future
Dave Longley: Alternative example, a system administrator has to provide a credential to access an administrative portion of a website. [scribe assist by Manu Sporny]
Tim Holborn: Perhaps just an example would be to provide a credential to edit a website
USE CASE: Given the opt-in permission of the participants (payer, payee, buyer, merchant) of a transaction, the transaction metadata can be used to discover additional attributes associated with those participants. For example, given the buyer's authorization, a merchant could query the identity URL for the buyer contained in a digital receipt and obtain an up-to-date email address.
Tim Holborn: Here’s a quick example: (not quite working, but press edit) http://mediaprophet.github.io/HTML5RWW-testing/index.html
Manu Sporny: This is about saying: once you've given a credential to someone, can they do further discovery of other credentials given your permission
USE CASE: Digitally verifiable credentials such that a merchant and payment processor involved in a transaction can prove that they have performed the proper due diligence when identifying the payer and the payee (KYC).
Manu Sporny: This is important because of regulations in the financial industry and some require the banks to prove that they know who their customers are, to prevent money laundering and for anti-terrorism initiatives, etc.
Mark Leuba: Can we go back one step to the permission to perform further discovery, at some point in time we'll need to be able to revoke that permission
Manu Sporny: You're right and we don't have that in the use case right now and we should clarify that
Manu Sporny: We should have a discussion on that as we've put a lot of thought into that in the last couple of years
USE CASE: A payer executes a transaction without revealing secrets that are not vital to the transaction (e.g. identity, passwords, PINs or other information that the merchant does not need to know).
Manu Sporny: This use case is basically about making sure that this credentialing mechanism doesn't expose extra information that you don't have to, if someone needs to prove you have a gov't issued passport, there should be a credential that can indicate you *have* a gov't issued passport that doesn't have to hand over all the information on it
Manu Sporny: This is the ability to be able to send only the minimum amount of information that is needed
Manu Sporny: If you want to order a bottle of wine on the web all you need to do is be able to prove that you're above the required age limit for your country
Manu Sporny: They dont need to know your exact age or birthdate, etc.
Manu Sporny: And you don't need to have your identity compromised
Chris McAvoy: (Have to drop early, thanks everyone)
Tim Holborn: GPS -- the question is about whether or not we're supporting the capacity to lower the resolution of the data you're sharing.
Tim Holborn: For example it currently gives point data on mobile phones, you can figure out exactly where the person is standing, whereas some services can translate point data to states, countries, etc., can we lower the resolution?
Manu Sporny: I think this is that use case, it's about lowering the resolution to the minimum necessary to pass whatever the merchant or receiver needs to verify about you
Manu Sporny: We don't have any use cases or things of that nature about that sort of tracking, but we're not talking about APIs for websites to access GPS stuff, etc. So the question back to you is, specifically, which one are you concerned with addressing? The pervasive monitoring and tracking of someone's location or the more general problem of lowering resolution to min required?
Tim Holborn: Facebook messenger can create authentication with that login and there are prefereneces that go with that handshake. Credentialling, the ODRL may be the other side of it, so i think that some of those things are in scope. I'm not sure, it also comes to the point of ... is this scope within the tech and spec process and to look if someone is not abiding by ... is it some sort of contact,... if you have a cred, and find out someone was using that credential in a way that isn't what you authorized how is that defended or rescinded
Manu Sporny: Once you give someone a piece of data you can't get it back so we have to deal with that -- so is there some way we can bring contract law into that, it's like a reverse shrinkwrap license, by accepting this data you agree to these privacy settings i've attached to it, so if you're going to use the data you have to comply with these ... we don't have a use case for this right now and that would be great if you wrote some up
Tim Holborn: Do we have any use cases around reputation?
Manu Sporny: Not yet
Tim Holborn: Can users identify reputation of one from another (credential issuer)?
Manu Sporny: I do see there being a vocabulary for helping with that, we're looking at this as letting the market decide trust, if for whatever reason company X shouldn't be trusted then people with signatures from that company will start getting rejected in the market
Manu Sporny: Even if that argument exists that doesn't mean there shouldn't be a standard vocab everyone uses for that, that's what we can standardize here.
Tim Holborn: If you can get the password to their email address you can reset all their passwords
Tim Holborn: A state-based bank, a passport-provider, there are high stakes creds and other creds. I guess that makes some sense. In AUstralia, in order to get a bank account, you need a certain number of "points", you need a birth certificate which is worth a certain number of points, a healthcare card which adds more points. There must be a digital equivalent of this, ranking of creds.
Manu Sporny: Yeah, please send the use cases to the mailing list
Manu Sporny: We're at the top of the hour, we have around six use cases left, we'll cover that on the call tomorrow.
Manu Sporny: Any closing thoughts/or announcements before call next week?
None
Manu Sporny: Thanks everyone
Bill Gebert: Thanks
David I. Lehn: Bye