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. ✪
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. ✪
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: 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. ✪
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: 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: 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 ✪
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 ✪
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 ✪
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. ✪
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 ✪
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 ✪
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 ✪
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.
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? ✪
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? ✪