Manu Sporny: We have a new version of the HTTP Signatures spec, with minimal changes so it won’t expire. We had a bunch of emails that it had expired and concerned that we wouldn’t take it forward. ✪
Topic: Introductions to New Members
Carla Casilli: You may know me from Mozilla and Open Badges, noew working with IMS Global. ✪
… We’re looking at interop within education. We’re looking at Digital Credentials and metadata/criteria needed to build-out Open Badges.
… There are three different teams working on this, with about 5 months to go. We’re looking at frameworks and requirements for interoperability.
Chris Webber: Would it be useful for me to give a brief introduction? ✪
Chris Webber: I’m Chris Webber, working on the W3C Social Web WG. We’re working on ActivityStreams/JSON-LD federation standard for having an experience between decentralized sites. Credentials are important for this. ✪
Carla Casilli: Hey everybody. Glad to be here. If you would like to connect my contact information is as follows. email: ccasilli@imsglobal.org ; twitter: @carlacasilli ; skype: cmcasilli ✪
Manu Sporny: We’re prepping for two presentations at the end of October at TPAC. There’s one on the credentials work; it tries to summarize the survey we sent out; we’re up to 43/60 responses. ✪
… The responses are randomized and specifics made generic. There are a bunch of graphs which are also in the presentation that underscore the types of capabilities people are looking for.
… We lead among all the groups that are discussing next-gen payments and related activities.
Topic: Credentials Reference Implementation Demo
Manu Sporny: The demo shows the entire credentials eco-system. ✪
… The eco-system has 3 major actors: issuers (e.g., DMV, Passport, Education Institutes …).
… Also Identity Providers who store credentials on your behalf. About anyone can become a provider.
… And the third group are credential consumers, those who need to see credentials for some form of proof (access to bank account, completion of degree, …).
… The goal of the group is to be sure that each of the actors plays in a level playing field, and interoperability is key.
… The demo shows all 3 actors operating; it’s focus on TPAC specifically for the interest of payments.
… They’ll re-visit the discussion that was tabled over the summer.
… The first demo is payment-specific. The second is more open/free on Wednesday, that talks about education/healthcare concerns.
… Entry point is to create an account on an Identity Provider (IDP), such as Google/Facebook/Twitter, but could be school or business.
… (shows creating an account)
… Where it deviates from normal sign-up, you get a popup for a polyfill, which gives you a decentralized identifier. The credential is assigned to something that is portable, different from email or social media addresses. This allows the solution to be user-centric so the user is responsible for their own credentials, and not tied to something owned by someone else.
Chris Webber: Are there links to more decentralized identifiers stuff? ✪
Chris Webber: It being not linked to domains sounds great ✪
Dave Longley: My comment is to point out that the window that pops up is something that would be standardized in the future. ✪
Henry Story: You’re thinking of this as part of the credential management API. ✪
… Is the identifier are URL or a URI?
Tim Holborn: V.bad echo. please turn down speakers... ✪
Dave Longley: It’s intended to be a URL or URI with the “did” scheme, that can be fetched. ✪
Chris Webber: I have a question once henry's question is resolved ✪
… The reason for a new scheme is to create a way of specifying decentralized identifiers. Http URLs are tied to a specific location, so are not appropriate.
Henry Story: If you loose your private key, you can loose access. ✪
Manu Sporny: We can also use HTTP URLs, but if you don’t have control of the URL (which you can’t really), that is compatibile with this sytem. We thing that DIDs are a great solution, though. ✪
… Also, if you lose your PK, you can delegate access to the DID to other people or organizations, so that even if you loose your PK, you can update the document with a new key. We don’t thin this suffers from the kinds of problems BitCoin suffers.
Chris Webber: This sounds interesting. Where are these stored, and what is ussed to retrieve a DID? ✪
Manu Sporny: In the future, they’ll be on a WebDHT; this technology has been around for around 15 years. We need to bring the technology on the web Rather than create a new protocol, we can build it on top of HTTP/HTTPS. ✪
… The way it’s stored is in a DHT, and retrieved using HTTP to hit nodes in the DHT to find the data you’re looking for. In the Polyfill, it’s sotred on authorization.io, with a REST-based API. THat will continue to be exposed in the future.
Henry Story: It will be interesting to make sure we can do this in an orthogonal way, so that WebID could be based on this. ✪
… We should make sure that HTTP/HTTPS onion-URLs follow the same kind of process so that people can choose the type of system the like, with competition/creativity among providers.
… IF the main notaion of a WebID is a reference to a person, then it’s powerful enough to cover all these kinds of cases.
Tim Holborn: Does WebID = Agent? or Legal Entity? or Person? ✪
Dave Longley: What you’re saying is inherent in the design. It’s like a WebID with a URL you follow to get information about the person. There’s a concept of a DID you can choose, so that it follows you around instead of being tied to a particular domain. We support any kind of URL, but we’re showing the DID concept. ✪
Manu Sporny: We’re proposing what we think the ideal is, but make sure that it’s open to other solutions. ✪
… (continues demo) Creating a DID, stored in the browser local storage. This returns a DID back to the IDP.
… (account created, associated with DID), now I can create credentials)
… (goes to another site which is an credential issuer). It requires that I log in, and I use my DID.
… YOu can use crypto, selecting identity (from local storage), which completes login.
… I then get a drivers licence (shows JSON-LD representation of DL, tied to DID).
… It has several claims (name, image, birthdate, gender, address, …)
… Also includes signature linking to DMV as signer.
… You create the Credneital and it goes back to IDP, who stores credentials. The signer has no idea what IDP is used to store the credential.
… Middle-ware intermediates moving the credneital between sites, so it’s never used to connect one service with another directly. You can store PII once things are complete, so that it can’t be later hacked.
Tim Holborn: What do browsers need to do to make this work if anything? ✪
Chris Webber: I don't have questions, but I think I need to get a list of all relevant specs ✪
Henry Story: You go do the DMV, login with your ID (DID), they sign a document saying that the person with the DID has various properties. The browser accepts the Cert in the browser, where it can be stored at an IDP, or stay in the browser. ✪
… When someone asks for your DL, you can send it from your IDP or browser.
Manu Sporny: Goes to a credential consumer. You create a bank account, they can pre-fill information by submitting a drivers licence, a cert version can ensure that information is not fraudulant. ✪
… I submit my DL, it goes back to middleware, where I select my identity, which takes me to my IDP. They see that someone has asked for the DL, but they don’t know who.
… If it know who was asking, they could violate your privace. The IDP gets a request, and the user can select it in their browser, with verifiable data.
… I click “done”, and the browser takes the credential back, and asks to be sure to send it back to requester, and the user sends the credentials from the browser.
… I send it to the bank, and it can verify it, and proceed with signup.
Gregg Kellogg: What does the bank need to do to verify that credential. [scribe assist by Manu Sporny] ✪
Manu Sporny: First step is to check basic syntactic validity. It can then fetch the PK, to be sure it matches. ✪
… It checks to be sure the issuers signature is valid, but needs to be sure the issuer can be trusted.
… It’s up to the recievers to choose the issuers they trust. For an example, for an international DL, the US might trust it’s alies, but not someone else. THey would have a list of organizations they accept credentials from.
… There could be deepter information, link-back to issuer to be sure it’s not revoked, but no link back to IDP.
Nate Otto: +1 On that countersignature by the credential's recipient. ✪
… The credential is counter-signed by the holder of the credential in addition to the issuer. The holder signs when the send it to a consumer.
… This prevents replay attacks.
Henry Story: If there’s a way for the consumer to say what kind of credentials the accept (who they trust), so the client can filter among stored credentials. ✪
Dave Longley: We’re looking into that; they could specify properties of credentials they want, and may also show the set of issuers they trust. ✪
John Tibbetts: I still find it hard to visualize are the workflows among the parties. This would be a great topic of a future Manu-Cast. ✪
… Say I have a credential that asserts my age, I have a phone and go into a bar to order a date. What would the transaction look like?
Manu Sporny: There’s a privacy component to your question, you really don’t want to reveal anything other than your age. Not even exposing your DID. ✪
… To get the credential, you go to an issuer, who proves your identity (utility bill, SS card) and may issue multiple credentials to you. It could be afull passport, but also a credential simply asserting your age.
… When someone needs to know your age, you could show just the credential that asserts the miminum they need to know.
… Another approach is called a “Bearer Credneital”, that can prove something in a pseudo-anonymous way. This would allow a single use of something that didn’t actually assert your ID.
Tim Holborn: Does a mechanism exist that discourages groups from demanding more information from a credential than is required for legal purposes? ✪
Dave Longley is scribing.
Manu Sporny: Yes and no. The way that the system works right now is that the consumer queries for a set of attributes that they need to know about you. ✪
Eric Korb: So, at the liquor store, they would have you scan a QR code that would request your ID. ✪
Manu Sporny: So if they just need to know your name the query is just name and you're taken to the IdP to prove your name. Your Idp shows you 20 creds with your name. We're hoping the software and the people make it obvious that you pick the credential(s) with the least amount of information. It's up to you to decide what you ultimately hand over. ✪
Tim Holborn: Given the potential explosion in identity requests, has any consideration been made into reputation? ✪
Tim Holborn: Ie: perhaps using ontologies to describe what might be required to fulfill particular requests. ✪
Eric Korb: A privacy question: As a best practice, I suspect that we would not want people to publish credentials on a public website that contain their DID. If they did they could be tracked. If I publish my driver's license on linked in then people could track me with any credential I ever put out there. ✪
Manu Sporny: Maybe, it just depends on how public you want that particular identity to be. You can have many identities. Maybe it's your public identity and you get credentials for it and publish those and you don't have a problem with exposing that information. ✪
Tim Holborn: Ie: if an adult website or online game, that may simply require name or proof of age, requests more information for say - ‘free credits’ , perhaps reputation plays a role? ✪
Manu Sporny: There may be requirements to keep things hidden, however, sometimes. Like any healthcare credentials. ✪
Tim Holborn: I imagine part of that is beyond the scope of credentials spec. Yet support for ontological functional adaption may need to be included? ✪
Manu Sporny: There isn't a clear answer to the question, it follows practices of today, some things you want public and some things you want private. ✪
Eric Korb: So, that makes a case for multiple IdPs ✪
Carla Casilli: You answered some of the questions I had, one was about atomic level credentials, not needing everything in a credential, just a few bits of information. So my other question, your provider is saying "Here are five credentials that are being requested of you." I'm wondering about the owner of these credentials and how people juggle that? Will IdP help handle that, if so how? ✪
Manu Sporny: There is a competitive marketplace for IdPs and one of the factors would be how well they help you select the credentials to use. ✪
Manu Sporny: An Idp could say this is the credential you should share because it exposes you the least amount of information. Another might say "You use your driver's license all over the Web, just go ahead and use it again." ✪
Manu Sporny: It's up to IdP software to compete to help you the way you want. ✪
Eric Korb: By default credentials are private, you have to make them public by choice. ✪
Tim Holborn: Privacy by default; for the entire credential? or for elements of the credential? is it all or nothing? ✪
Henry Story: What I was thinking of is, I suppose one reason for integrating the IdP in the browser is that if you authenticate to one site with 3 different credentials, then in fact they can get the sum of that information. If the IdP doesn't know who you are connecting then it can't help you make certain decisions. It seems like you'd need that sort of thinking for automation. ✪
Henry Story: On the other side, imagine if you had different IDs, one for your age, one for your driver's license, one for membership of a club, you could have other credentials that identify those? You could have as many of those credentials that identifier (owl:sameAs relations). ✪
Manu Sporny: Yes we want to automate these processes as much as possible. ✪
Dave Longley: Quick response - there are other technologies out there that don't fully provide all features that we need. Some of these other protocols, the way the protocol is designed requires the IdP to know all sites you're logging into. [scribe assist by Manu Sporny] ✪
Dave Longley: You can provide the IdP with where you're logging into, but that is not shared by default. [scribe assist by Manu Sporny] ✪
Tim Holborn: Has any consideration been made into reputation? ✪
Tim Holborn: Ie: perhaps using ontologies to describe what might be required to fulfill particular requests. ✪
Tim Holborn: Ie: if an adult website or online game, that may simply require name or proof of age, requests more information for say - ‘free credits’ , perhaps therein a mechanism around reputation might play a role? ✪
Tim Holborn: Thereafter: i imagine part of that is beyond the scope of credentials spec. Yet support for ontological functional adaption may need to be included? ✪
Tim Holborn: Therein; by privacy by default; is that for the entire credential? or for elements of the credential? is it all or nothing? ✪
Manu Sporny: "Are there any ontologies for requests?" The requests use linked data so we can arbitrarily extend them in the future as needed. ✪
Manu Sporny: RIght now they are attribute based. ✪
Manu Sporny: Yes, you can have reputation-based credentials, absolutely. ✪
Manu Sporny: I don't know what you mean by "ontological functional adaption" ✪
Manu Sporny: When it comes to a credential itself, it's all or nothing (in terms of privacy), because of the limits of cryptography at the moment. We can ask issues to atomize the information as much as possible. ✪
Dave Longley: It's all-or-nothing right now, there are cryptographers working on getting around this but there are lots of limitations right now. ✪
Manu Sporny: It's up to people in the market to create and publish reputation ontologies and issues to use them, etc. ✪
Tim Holborn: Sorry - i copy and pasted it to make it easier for you… cheers. i’ll follow-up on the list. ✪
Henry Story: What is the relationship with HTTP signatures? ✪
Manu Sporny: They are designed to give you access to this system. They are meant for machines or agents to be able to access Websites. ✪
Dave Longley: The flow that we showed today is a browser-based API [scribe assist by Manu Sporny] ✪
Dave Longley: In the future, you may give automatic access to certain credentials to certain consumers - in those systems, where you are preauthorized, there are the issuers and consumers - they use HTTP Signatures to authenticate. [scribe assist by Manu Sporny] ✪
Tim Holborn: Is it possible to make hierarchical credentials that create in effect a package of crednetials? ✪
Tim Holborn: Ie: a drivers license is made up of several child credentials…? ✪
Tim Holborn: For trust purposes, they might want the age you’ve listed on your DL ✪
Dave Longley: So what gets sent to the consumer is an "identity document" with a bunch of credentials ... which, with JSON-LD processing ends up being a doc with a bunch of attributes on it for use ✪
Dave Longley: Anyway, this stuff is all linked data, so it's fairly flexible ✪
Dave Longley: We don't know what people will want to put in these credentials and we don't pretend to know it ... so we get out of the way and let people innovate. ✪
Tim Holborn: Understood… With a Digital Cinema Package or DCP. ✪
Dave Longley: We just want to ensure interop ... and then let markets evolve as needed. ✪
Chris Webber: Be warned that's pretty out of date. [scribe assist by Dave Longley] ✪
Tim Holborn: I think the simple version, is that i’m thinking about a tree structure. So the child results are simple claims like age, etc. the parent record might reference those claim documents and use them to create a ‘parent’ claim, for example - drivers license. Theory being around whether it’s possible to in-effect create a credential where a check-box (for instance) could be used to select that ‘age’ element, of a DL. ✪
Chris Webber: Dlongley, is there newer material I should read? ✪
Dave Longley: Paroneayea, don't pay attention to any of the REST API stuff. ✪
Tim Holborn: Being that it is part of the ‘trust provider’ delivered by the motor authority ✪
Tim Holborn: Yet, don’t need to supply the entire claims chain, contained within the parent cred. ✪
Dave Longley: The stuff in the Identity Credentials spec regarding how things are marked up isn't too far off ✪
Henry Story: I suppose one question is how does the idp send the credentials to the Relying Party? In OpenId it is via a redirect, but that requires a URL with encoded attribute values. Is there another way? ✪
Dave Longley: It's worth reading that spec anyway, just know that a lot of what was in the demo hasn't been updated in the spec ✪
Dave Longley: Mediaprophet, there are certain limitations based on cryptography for plucking out bits of a doc ✪
Dave Longley: Essentially `navigator.credentials.get()` is called on the consumer site ... just like the Credential Management API ✪
Dave Longley: It returns a Promise that will resolve, eventually, to the credentials (or "identity document containing credentials") selected at your IdP ✪
Dave Longley: Similarly, you call `navigator.credentials.store` at the issuer site to store something ... it returns a Promise that will resolve once you've done something at your IdP. ✪
Dave Longley: And this is all polyfilled with postMessage and iframes and such. ✪
Dave Longley: (Full source available at that link) ✪
Dave Longley: That's the code the `authorization.io` site runs that acts as the part of the browser that would run the flows and display your IdP and so on. ✪
Tim Holborn: Nb. before manu picked-up the questions, i copy / pasted them, trying to make it easier… so in effect, there’s duplicates ✪