The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2014-09-23

Agenda
http://lists.w3.org/Archives/Public/public-credentials/2014Sep/0023.html
Topics
  1. Complete Web Payments Use Case Review
  2. Identity Recovery
  3. Use Cases from Tim Holborn
  4. Generalized Credentials
  5. Read/Write Permissions
  6. Proof of Delivery
  7. Sharing Private Data
  8. Credential-based Access
  9. Confidential Sharing/Agreement
  10. Advertising and Data Rights
  11. Credentials for Internet of Things
Organizer
Dave Longley
Scribe
Mary Bold, Manu Sporny
Present
Dave Longley, Mary Bold, Eric Korb, Bill Gebert, Manu Sporny, Mark Leuba, David I. Lehn
Audio Log
Mary Bold is scribing.
Dave Longley: First up on the agenda: completing the Web Payments use cases.

Topic: Complete Web Payments Use Case Review

Dave Longley: Last meeting, we were talking about a payer Jack sending money to Jill--asking for an identifier
USE CASE: Gunther (payer) enters a short-identifier that he believes identifies The Widget Store (merchant) into a UI. The UI displays a certificate of authenticity that indicates the short identifier is in fact for The Widget Store. Gunther uses the short identifier to make a payment to the store.
Dave Longley: The next use is related to that: Gunther, who is the payer seeking the Widget store (see text of use case).
Dave Longley: In this case, it's Gunther wanting to pay a store for a widget.
Dave Longley: We reviewed this in Web Payments community group and looked at feedback == now cleaned up.
Dave Longley: Does anyone here today have any feedback or questions about this use case?
Eric Korb: A store... or any entity trying to transact with that person?
Eric Korb: If a university...
Dave Longley: Yes, it would work in the same way: a short identifier to map to any entity.

Topic: Identity Recovery

Dave Longley: Design Criteria: A primary entity (buyer, merchant, etc.) with access to a credential service sets a second entity (buyer, merchant, etc.) as a backup for accessing their credentials should they inadvertently lose their ability to access the credential service (accidental loss of password or 2-factor authentication device).
Dave Longley: Moving to the last case from the WebPayments CG: design criteria.
Dave Longley: Back-up for accessing credentials--accidental loss of password or 2-factor authentication
Dave Longley: Person loses password--ability to recover access to your account
Dave Longley: Overly complex to try to put into the standard. We can let best practices and the market decide the direction to proceed.
Dave Longley: We're going to leave the use case in there as something to consider. The complexity doesn't buy us anything. It would best to let individual identity providers decide what recovery measures to offer their customers.

Topic: Use Cases from Tim Holborn

Dave Longley: If no comments... Let's look over Tim's use cases; I don't think he has joined us yet.
Dave Longley: Tim's original email is provided by link; Manu edited to make the list easier to digest.
Dave Longley: Something that struck me: we need to have a brief discussion on definition
Dave Longley: My view of credential meaning: a credential a set of provably authentic statements. Provably authenthic = someone actually endorsed.
Dave Longley: Other clarifying statements?
Eric Korb: Couple of things around credentials: the word, proof, can have different meanings. Evidence = artifacts that go along with the credential on what you demonstrated. I prefer the word, claim.
Eric Korb: I claim I have a driver's licence. The proof is a link back to the document issued to me. Maybe Mary can add some words.
Dave Longley: Need to distinguish between someone making a statement, and the truth of the statement itself.
Dave Longley: Follow evidence links to confirm, it is like this statement is true. Beyond confirming that someone said it. If you trust the party, you may assume it is true--but different matter.
Eric Korb: We've been dealing with the word, evidence, which would link to a portfolio (example).
Eric Korb: Link is to the actual piece of art that prompted the credential. Similarly, evidence could be from a test. Maybe Bill Gebert has some more words about how they address.
Bill Gebert: Eric, thanks. Nice job describing from educational focus.
Bill Gebert: Many of the credentials that ETS produces are high stakes.
Bill Gebert: Ex: higher education in U.S., U.K., Australia, etc.
Bill Gebert: The element of high stakes is crucial. The issuance of those credential requires secure.
Manu Sporny is scribing.
Bill Gebert: I just wanted to add from an education perspective, it's really the supporting evidence and the security of that evidence that gives the credential its weight.
Dave Longley: I think these are all good points, speak to underlying nature of credentials and how technology will be useful.
Mark Leuba: Parallel with a government document, I think you don't simply say "I have a license", you have to present the document. In order to get that document, you had to provide certain behaviors - you had to pass certain tests.
Mark Leuba: With respect to education, wouldn't it be the document that was endorsed? It seems to me the presentation of something that you have that is vouched for via an accredited authority, the credential is "free"?
Bill Gebert: I think that's partially correct, maybe fully correct, there is a slight twist to it - proofing of identity of the person claiming that credential. Everyone has read stories of people impersonating others to take high-stakes examinations to get the appropriate scores to be utilized. So, it's not just the credential, it's the combination of the credential and the proofing of the person that claims that credential.
Mark Leuba: That makes a lot of sense.
Dave Longley: You could present two credentials - a driver's license and a picture of your face (issued by USPTO). You can combine credentials.
Dave Longley: The point I was trying to make wrt. differentiating the assertion that a credential is true is that, at its core, the most basic type of credential you can have is a set of statements about an identity that can be digitally signed. The actual evidence might not be in the credential.
Dave Longley: You may not have to show the evidence at all. It's important that we support the ability to attach evidence, one that asserts identity. The only thing we need for a core credential is a set of statements that is signed by some party. If you trust that party, you assume that the party did what they need to to issue that credential.
Eric Korb: I don't know if we use the word "prove" or "claim".
Dave Longley: We may need to do some wordsmithing with the defintion, but we have a general idea of how to move forward. A credential is a set of statements that has been digitally signed, so that a verifyer can look at that set of statements and can verify the information. You know that the issuer of the credential is that actually issued it.
Eric Korb: The proof is beholden on the issuer. We trust them to protect their keys, we trust them to sign proper information.
Dave Longley: I'm going to start going down the consolidated list from Manu's email.

Topic: Generalized Credentials

Dave Longley: Design Criteria: Support the following types of education, government, and healthcare credentials
Dave Longley: The first thing we have is a design criteria - it tries to make a generic case out of credentials.
Dave Longley: + I have a education degree in field X
Dave Longley: + I am a student, studying in field Y
Dave Longley: + I am a lecturer at university Z
Dave Longley: + I am a citizen
Dave Longley: + My date of birth is, etc.
Dave Longley: + I have a prescription / right to purchase this medication
Dave Longley: + I am an Emergency Health Professional
Dave Longley: + I have a valid First Aid Certificate
Dave Longley: + This is my Vehicle
Dave Longley: + This is my registered trademark
Dave Longley: + I have a yacht-club Membership
Dave Longley: + I am a Webizen
Dave Longley: + I work at Fast Food Chain xyz - Please authorise my discount
Dave Longley: + I work at Telecommunications Company XYZ: Let me in the door to this secure facility
Dave Longley: + I am a lawyer or Accountant
Dave Longley: + I am a Lawyer or Accountant representing this client
Dave Longley: These are all the types of credentials we could support.
Dave Longley: All of these fall into a generic scope for credentials. If we use JSON-LD to represent these credentials, we can use any number of vocabularies to assert these credentials. All of these are supported by the technology. We could talk about individual ones if people would like, but most of them fall within the notion of credentials. These are statements about stuff that can be digitally signed.
Bill Gebert: This is the beginning of a list that could be thousands of entries long.
Dave Longley: Yes, we're not going to be able to create a list of all credentials that can be created. It's up to the market vertical to figure this stuff out.
Dave Longley: There are three use cases here that we may want to move over to Web Payments:
Dave Longley: + I purchased this TV within the last 12 months (i still have a warrantee)
Dave Longley: + I paid this bill on this day
Dave Longley: + My insurance for my yatch is paid

Topic: Read/Write Permissions

USE CASE: Enable access to patient storage for particular individuals.
Dave Longley: + I authorise this doctor to write to my patient record
Dave Longley: + I deauthorise this doctor to write to my patient record
Dave Longley: + Emergency Health Providers can Access my Patient Records
Dave Longley: We need to make sure we don't extend the scope too much.
Dave Longley: I think we're in a gray area here on whether or not this should fall into the Credential work. We could use authorization as a way of accessing credentials - medical records are just another form of credential.
Dave Longley: A doctor can write a statement to your record to say "You have a particular disease X"
Dave Longley: Another thing might be a 'vaccination credential' - don't know how well this use case fits into credentials work.
Bill Gebert: I sort of agree with you, this is almost permissions, not credentials.
Bill Gebert: I don't understand where this fits in w/ credentials.
Manu Sporny: This has to do with WebACL and permission access to arbitrary data. I don't think we should try and solve that problem here.
Dave Longley: Yes, I don't think we're talking about telling identity providers how they should go about handling permissions. Who is allowed to write/read, etc. It's important that we have a protocol for allowing those writes to happen, but I don't think we're interested in creating the WebACL specification to do that.
Dave Longley: We're concerned with the protocol that allows you to do the reading/writing, but I don't think we should try to standardize the whole permissions stack.
Eric Korb: We also should be careful about not mixing the idea of a credential. A prescription is not a credential.
Eric Korb: We're not talking about reports, we're talking about credentials that make a claim.
Eric Korb: I do like the idea of making a claim "My doctor can have access to my health report", but I think that's where it ends.
Dave Longley: I think if we go on, not having a permanent credential, transitory credentials, we'll get into that as we go along.
Dave Longley: Any more feedback on this use case.

Topic: Proof of Delivery

USE CASE: A sender transmits some data to a receiver. The receiver transmits a digitally signed certificate of delivery to the sender.
Dave Longley: + I have sent you legal notification digitally
Dave Longley: + I have authored this document which i seek to be delivered as
Dave Longley: Registered mail to the named recipient
Dave Longley: + I seek a date-stamp (and checksum) on this document send to the
Dave Longley: General consensus seems to be that this is out of scope, we do want to support certain aspects, but not that interested in standardizing Access Control Lists, and that work is supportive of what we're doing here.
Dave Longley: Specified recipient.
Dave Longley: (And i seek to declare terms to that transmission)
Dave Longley: This is an example of a use case where we're getting into transitory credentials. I'm not sure what the utility of this statement is, number of different use cases where we could fill out specifics. I guess you might want to prove that you did infact send a legal document, like a summons.
Bill Gebert: This seems like a receipt confirmation, from a traditional ecommerce transaction. The use case itself might really be better worded as "certificate of receipt from sender".
Eric Korb: Is this like DocuSign? At the end, you get a list of all of the handoffs back and forth.
Dave Longley: I think it could be very similar to that.
Manu Sporny: I don't know if we want to support this use case. There are two parts to it. One of them is a 'proof of delivery' part, the latter is the piece of paper itself (the proof).
Eric Korb: The credential itself is part of a bigger package, it's a subset of a transaction.
Dave Longley: I think that's true for the commerce case, there might be a use case where you don't exchange money. You can still use ecommerce APIs to accomplish that, but maybe you wouldn't want to. This seems pretty open ended for the first cut of the technology. We already support the notion of writing arbitrary credentials to a particular identity. I think that covers the aspects of this that we'd be interested in at this point.
Eric Korb: With the TrueCred APIs, we have this concept of 'claims'. Isn't a 'claim' considered proof of delivery?
Dave Longley: I think in that approach, we store something as a claim itself - not the 'proof of delivery'.
Dave Longley: This seems like this is out of scope to a certain extent. What we do have in the technology does support this. This is too generic of a use case for us to say whether or not this clearly fits in w/ what we want to do. It's too easy for us to say "this is ecommerce" or something to that effect.
Dave Longley: If there are no other comments, we can move on.

Topic: Sharing Private Data

USE CASE: Credentials issuer seeks to share private information (web resources) with credentials holder.
Dave Longley: Feedback from Manu: Why is this use case not covered by SSL? Do you mean that the Credentials issuer needs to write information to the credential holder's online storage?
Dave Longley: If we're just talking about writing to credential holder's online storage, we have that technology already. I'm not sure what this use case is about. I think it's supposed to be about privacy, this might be related to the Data Rights stuff that Tim has been talking about.

Topic: Credential-based Access

USE CASE: Individual is fined for traffic infringement and seeks access to Video (and/or audio) evidence recorded by law-enforcement. A means is sought to do this privately (as to avoid the material being published on youtube).
Dave Longley: "I only authorize this information to be shared with you for these reasons"
Dave Longley: This sounds like a fairly standard case of using some credential to allow you to view some evidence. This is fairly well within what we're trying to standardize here. I don't know if it needs to be reworded? Maybe we could be more specific about the type of credential shown.

Topic: Confidential Sharing/Agreement

USE CASE: A confidential document is being distributed for the purpose of disclosure and mutual agreement.
Dave Longley: Manu's feedback: Why can't the distribution happen over SSL? Do you want the document to be transmitted over SSL and for the contents to be encrypted to the receiver? Then have the contents digitally signed and re-encrypted to the sender?
Dave Longley: It's not clear whether this needs to fit into the credentials work, it's just typical transmission of information from one person to the other over an ecrypted channel
Manu Sporny: I don't see what this has to do with credentials. The only thing it has in common are digital signatures.
Dave Longley: We are using encryption, cryptography, and digital signatures in this group, but that seems to be the only connection. There is some overlap with the technologies, but that seems to be it.
Dave Longley: I think we should mark this one as out of scope.

Topic: Advertising and Data Rights

USE CASE: I have a hybrid TV service (Broadcast + Broadband) here is my identity details, i would like to control who and how this information is used for targeted advertising & other purposes.
Dave Longley: Might want to remove the hybrid TV service bit, don't know why that's
Dave Longley: Relevant? Maybe because of the advertising angle? You don't want to be
Dave Longley: Advertised to using your identity information, but you need to use it to
Dave Longley: Unlock the "over the age of 13" channels?
Dave Longley: In this use case, this is about data rights. It's about being able to present a credential to say you have access to certain services /but/ don't sell my information to advertisers.
Dave Longley: This fits in w/ showing a credential to get access to services, and then work with data rights vocabulary, where the credential can only be used in certain ways. We should clean up this use case a bit, maybe after that we can fit it into version 1.

Topic: Credentials for Internet of Things

USE CASE: This intelligent light globe is connected at my home. I would like access to the light globe to turn it on/off remotely.
Dave Longley: Seems like a secondary case for authorized access to IoT device? Don't
Dave Longley: Know if we need this one, as others should cover it.
Dave Longley: I agree, this feels like it's just another access control to a service issue. Where access control might be determined by presenting a credential.
Eric Korb: I agree.
David I. Lehn: Agreed.
Dave Longley: There is another more advanced list of use cases, most of them applied to Web Payments, but for today I think we're done. We can't get into those.
Dave Longley: Any other thoughts/questions wrt. call?