Laura Fowler: I'm a principal enterprise architect for ETS. I've been asked to sit on this meeting in place of Bill Gebert. He's unable to join on a weekly basis, I'm sitting in for him and working with our teams on badges and credentials. ✪
Topic: Introduction to Brent Shambaugh
Brent Shambaugh: I've been spending the past year or two with the Web Payments CG, I'm here because I'm looking at applications to enterprise and engineering tools and integrating Linked Data with those things and payments too. ✪
Manu Sporny: The minutes should be out for the F2F Web Payments IG meeting in Utrecht in a week or so. ✪
Manu Sporny: There's a summary link in IRC for an overview of what happened. ✪
Manu Sporny: Overall, we were expecting 18 people and around 30 showed up. We had a lot of great representatives there from large corps, including GSM, Rabobank, Bloomberg, National Association of Convenience Stores, World Pay, etc. big major players in the space. As far as credentials stuff is concerned, we went in making a case that credentials are important for the payments work, specifically for KYC and anti-money laundering and regulations, etc. and in general the group agrees. ✪
Manu Sporny: And we were able to get some fairly loose consensus around three items, 1. creds are important for payments, the group feels that a credentialing component must be exist to standardize web payments, 2. regulations can't easily be met without credentials, 3. if the Web Payments IG creates a WG for credentials, the work should be done in an independent WG just for credentials ✪
Manu Sporny: The group wants to look at the use cases we've done here which is really good. So it's all great news, we got what we wanted to out of the F2F meeting. ✪
Manu Sporny: We weren't able to spend much time looking at the roadmap and use cases, but in general, the Web Payments IG would like to work more closely with the Credentials CG over the next few months. We've got some work to do for any official work that might start up around the credentialling initiative. ✪
Manu Sporny: The one thing we may want to do differently from what we've been doing here. We've been focusing on technical stuff, but at some point W3C will want us to propose some kind of charter to float around W3C membership. We also want to start trying to get votes from the membership for this work. We've got 400 organizations we can make contact with and see if they'd like to support a WG charter for credentials. ✪
Nate Otto: Exciting progress. Thanks for travelling. ✪
Topic: Decentralized Identifiers for Credentials/Badges
Manu Sporny is scribing.
Manu Sporny: Nate, do you mind giving us some background? ✪
Nate Otto: A discussion came up on Badge Alliance standards board about ways to identify documents in a badge storage mechanism. ✪
Nate Otto: One contributor is frustrated w/ badge issuers that are hosting multiple documents, much like identity document, sometimes descriptions are changed, he wanted a GUID. ✪
Nate Otto: I remember the @id is a part of the Open Badges spec... we will have a unique identifier in the form of an IRI, so that will be compliant. ✪
Nate Otto: There may be a DNS-like infrastructure to look up badges back to the "document of truth". ✪
Nate Otto: Not sure if that's useful vs. just using IRIs. ✪
Nate Otto: We also had a discussion around the Experience API (xAPI). The xAPI group is building in support to transport badges. Looks like they built that spec off of the Activity Streams 1.0 spec. Looks like they've diverged from AS 2.0. ✪
Manu Sporny: We have a lot of thoughts in this area. We're concerned about vendor lock-in, we don't want vendors to create badges and then keep people from being able to move their badges around and choose where they store them, etc. We, meaning "Digital Bazaar" is concerned that using IRIs could lead to vendor lock in. [scribe assist by Dave Longley] ✪
Dave Longley: We have been talking about decentralized identifiers to prevent vendor lock-in. We want stuff to be portable, been talking about this in Web Payments for years. ✪
Dave Longley: We've been referring to them as "DID"s - decentralized identifiers. We've explored a couple of ideas like DNS-like systems, blockchain-like systems, decentralized query systems, etc. ✪
Nate Otto: I saw a demo of the "telehash" approach last summer. ✪
Dave Longley: Distributed hashtables to look up names - Manu wrote a blog post at some point. ✪
Dave Longley: You can do a query on a network to find pieces of information. All these sorts of ideas try to solve the same problem. How do you have an identifier for you badge / identity? Can you change where that information is stored? Can you have an opaque identifier? ✪
elf Pavlik: Which post? identity credentals one? ✪
Manu Sporny: Elf-pavlik, yes, the Identity credentials one. ✪
Dave Longley: So there are a number of things we've been discussing related to decentralized identifiers. ✪
Dave Longley: So, with the credentials work, we want some way to prevent vendor lock-in. We want to make portability possible. ✪
Nate Otto: Two points, I guess - we were thinking about using IRIs - low barrier to entry, everyone can resolve them. In order to prevent lock-in, we have this "authorization to issue on my behalf" credential? ✪
Nate Otto: Maybe identity can generate another ID - then authorize other platforms to issue badges for them. ✪
Nate Otto: Re-up on the authorization after a certain time period - prevent vendor lock-in, without needing a technical spec. A lot of the people that are issuing badges are probably not going to be keen on building in telehash or blockchains yet. ✪
Nate Otto: My main focus is to try to moderate BA mailing list - when questions get too big for badge alliance - like "what do we do for identifiers" - I want to push those questions into this group - into larger spaces. ✪
Nate Otto: We want to adopt larger technologies - ones that are more general. ✪
Dave Longley: With regard to people controlling their own domain - difficult for most people to do - but many people want to be able to control their own identity - they're going to end up using a domain that is not in their control. We don't want them to be locked into those "identity providers" or "credential storage systems". They're going to use a 3rd party to store their data. ✪
Dave Longley: And we want them to be able to move away from that provider. We can't rely on HTTP IRIs for it - I don't think we'd deviate from using IRIs... but they might not be HTTP IRIs, you might have to resolve them in a different way - coming up with another system that has a lower barrier to entry. People shouldn't have to buy a domain to be in control of their own identity. ✪
Dave Longley: There are several other layers of abstraction here - we don't think of vendors as ones that store badges, there's a dichotomy there - there is an issuer who can create the badges, then there is another organization that might store the badges. ✪
Dave Longley: There are several different components that could be combined into one entity, or they could be split out. Issuers wouldn't need to implement telehash. Someone could say "This is my DID", and then that's it. the issuer issues to that DID. ✪
Dave Longley: There are different layers of abstraction that we could put in to make it easier for issuers. ✪
Nate Otto: So a service dedicated to transport things between HTTP IRIs and some other telehash-like IRIs. ✪
Dave Longley: Yeah, there are a number of different ways that we could achieve this - we want data portability, we want to make it easy for people that don't have their own domain to still be in control of their identity. ✪
Nate Otto: Sounds like excellent goals - the ability to have the conversation here is good - we want to push this question out of BA mailing list to here. ✪
Nate Otto: My immediate "TODO" question - as we think about identity and identifiers - what should we do to make sure we'll be compatibile with something like this. ✪
Dave Longley: We expect this stuff should go into Identity Credentials spec or a companion WebDHT spec. ✪
Dave Longley: As far as creating documents/badges - as long as you're using JSON-LD and badge IDs are IRIs... what we will be creating, I think, are interfaces and protocols to indicate how to write to someone's personal set of credentials. That's the space that should be followed more closely. ✪
Brian Sletten: I support and agree with the larger intiative of data portability - and a telehash-like identifier. Is there a certain credential use case where people don't care about portability. The organization that's issuing it - if issuer is not in control of it, they don't care. ✪
Brian Sletten: Can we just fall back on resolvable IRIs - is that acceptable? ✪
Dave Longley: It's a design goal, it's not a design reality. Any sort of DID would be at a different identifier. You'd say "use this IRI" to write to my identity. ✪
Dave Longley: So, the issuer would assign credentials to a DID. ✪
Nate Otto: Most of our issuer organizations in the Open Badges world are orgs with their own websites... often the heavy lift is to do the editing on that site on a regular basis, not just getting and continuing to pay for the domain. So they are using badge-specific issuing platforms. A one-time site edit to add authorization doesn't seem too difficult for an organization in this case. ✪
Dave Longley: At a high-level, issuers would use HTTP to write... at a low-level, you can use a DID. ✪
Dave Longley: If we can make it easy for everyone to use a DID, we want to standardize on that. your point is well taken - we don't want to make this difficult for folks. ✪
Example of decentralized identifier: did:4873205982347592835723980 ✪
Manu Sporny: One addition to that, I agree with Dave Longley's comments and Brian you make a good point, we don't want to make issuing badges an arduous thing. That's not the proposal, rather, when you log into an Issuer Website, you give them your ID, today with OBI that's your email address or salted email address, etc. That's rev 1. In the future, we want to issue badges to a dereferencable URL. I could log into an issuer site, for [scribe assist by Dave Longley] ✪
Dave Longley: Example, using the URL in IRC. I could assign the badges to that URL. The downside is that once those badges are issued to that website I'm locked into it. If that site goes away or deletes my identity, etc. my badges are gone unless I can somehow prove I once owned that URL. Now we're saying you could tell the issuer, that instead of using HTTPS, please use my DID. ✪
Manu Sporny: Any badge assigned by the issuer would go to that DID and there's a lot of complexity underneath that (hidden away) and we want to make it as easy to use as possible. [scribe assist by Dave Longley] ✪
Manu Sporny: In the case that we fail to create a good decentralized id mechanism we just fall back to URLs [scribe assist by Dave Longley] ✪
Nate Otto: The Badge Alliance is extremely sensitive to issues that make the user experience difficult for credential recipients. ✪
Manu Sporny: The downside is we're going to create vendor lock-in; where there are very few badge "vaults" and little possible competition. W3c has created standards over 20 years that have vendor lock-in because the basic identifier mechanism leads to it. [scribe assist by Dave Longley] ✪
elf Pavlik: XDI is important - we should look at iName and iNumber - you pay for it... iNumber always stays with you - domain name doesn't expire. We could look at how XDI works - would be happy to invite him to the discussion. ✪
Victoriano Giralt: Do you know about OrcID? I wouldn't promote it - it's vendor lock in - unique identifier that you give to authors - so you can tell one "John Smith" from another "John Smith". You should be able to move that around with you. ✪
Victoriano Giralt: I'm not supportive of that, because of vendor lock-in - but maybe we can learn from it since they're becoming big in academic environments. ✪
Manu Sporny: There are a number of orgs that are setting themselves up as identifier organizations. GS1 is an example of this, barcodes, and IDs like that in the world, etc. What we're trying for here is a decentralized mechanism where you get to issue your own identifiers and claim them instead of having a centralized org do it for you. We don't want to create these super orgs that just hand out IDs to people. We think we have a bett [scribe assist by Dave Longley] ✪
Dave Longley: Er infrastructure this time around to solve this. We couldn't solve this in 80's and 90's as easy, but today we have a global community infrastructure that can generate IDs in a way that doesn't conflict, etc. The Internet, instead of creating an org that sucks up several million dollars a year and just issues IDs. ✪
Nate Otto: One of the other possibilities in Badge alliance - issue directly to public key? It is a solution to make sure things are decentralized, we'd have to build up quite a workflow around how to prove identity. ✪
Manu Sporny: One of the other things that came out of F2F, Ripple Labs and Ethereum were there, they've been involved in the bitcoin work as well, there was a lot of discussion around identifiers, blockchain tech and so forth. All these techs are in the same basic area and it's going to take some time for consensus for the right approach. Overall goal is prevent vendor lock in and make it easy to use, if it's not easy it won't be used. [scribe assist by Dave Longley] ✪
Dave Longley: One more quick thing - we've discussed how to use public keys to generate identifiers - there are a couple of drawbacks in the identity space... in Bitcoin, you don't care what your address is - if you have a problem, you just generate a new identifier and move your money over. ✪
Dave Longley: You might want to keep that identity for a really long time - if public key is compromised, how do you do that? ✪
Dave Longley: It's a much bigger problem than just switching addresses - a lot of your credentials are now linked to that identifier, but now that identifier is no good. It's a trickier business to switch keys. Generating IDs directly from cryptosystems have bigger rammifications on identity than cryptocurrencies. ✪
Eric Korb: More of a question than a statement - vanity domains - like .ceo - people are using those as identity - all those systems would be able to offer identity piece once we have this identity system sorted. ✪
Eric Korb: We don't want people to create identity for themselves at great expense. ✪
Dave Longley: It's not clear that we should go that path - layer on top of DNS - most people don't own their own domains. We want lower barrier to entry - don't pay for an ID. ✪
Eric Korb: Such as erickorb.ceo which is part of the peoplebrowser platform. ✪
Eric Korb: +1 Manu, that's what I wanted to come out. ✪
Manu Sporny: If we want this thing to be ubiquitous, we can't say that you have to spend even $7/year to buy an identifier. People won't necessarily want to spend that money for just a couple credentials and some people can't, and we want to reduce the amount of friction for creating a domain. Any one of those those .ceo, .me domains is a non-trivial amount of money in kenya, ethopia, even some people in the US dont' want a vanity URL, etc. [scribe assist by Dave Longley] ✪
Manu Sporny: That's why facebook and twitter are so pervasive, they don't have to pay anything and they can jump in and claim their URL. The problem is lock in. [scribe assist by Dave Longley] ✪
Dave Longley: I need a solid week to work on the spec exclusively - just a weeks worth of work on it - it's taking a while because I don't have much time to work on it. ✪
Topic: Badge Alliance Context/Vocabulary Update
Nate Otto: We have made a few changes over last couple of weeks - changes will be reflected in document in next week. ✪
Nate Otto: One of the main changes - additional terms - adding previous property to a badge, must be matched to a JSON-LD statement, we want to be compatible with Linked Data Signatures. Anyoen could implement LD signing mechanism as an extension. A valid JSON-LD data that could be added to a badge. ✪
Nate Otto: We're changing references to the word from "standard" back to "specification". ✪
Nate Otto: We made update to vocabulary document - term names. ✪
Nate Otto: The first thing - claim - property/value pair. Credential class - badge class is a specific set of claims issued as one set to many recipients so people can observe that many recipients received the claims. ✪
Nate Otto: BA thinks that there is a lot of value wrt. who has what set - endorsement work, a way for a 3rd party to endorse a badge class - say "this particular class has value". ✪
Nate Otto: A Credential collection - grouping of credentials. ✪
Nate Otto: Identity, which is an IRI acting as a common identifier - issuer, requester, endorser, etc. ✪
elf Pavlik: Could you tell me a bit more about a collection? Is there paging concerns, etc? ✪
Nate Otto: We haven't come up with how they will be delivered. Identity credentials does list JSON-LD representations of credentials... paging hasn't been addressed in that spec. Basically, you have a JSON-LD array. I don't think paging has been addressed. ✪
Manu Sporny: I think elf, you're alluding to the Linked Data Platform Container stuff, it means something very specific there. Are you asking a question about the difference between a Collection and a Container? [scribe assist by Dave Longley] ✪
elf Pavlik: Just wondering about the functionality - requirements. ✪
Nate Otto: Good question - I think one of our earlier use cases had to do w/ composition of credentials. One particular credential might not have enough information wrt. having enough information to prove something. 3-4 different validated statements presented together in format that could be understood. ✪
Nate Otto: Analyze trust relationship - powerful case to look at. ✪
Dave Longley: One point with respect to format for identity credentials - we designed with that in mind. If you look at the spec, the way the spec is laid out - each credential makes claims about a particular ID. The @id is the IRI for the identity. Each credential - the @id property is also the identity. ✪
Dave Longley: You can take all the credentials and merge via JSON-LD framing - check signatures, run through framing, and has a complete merged identity object for use. ✪
elf Pavlik: Could you make an example on the playground and send to mailing list? ✪