W3C home > Mailing lists > Public > public-credentials@w3.org > September 2014

Credentials CG Telecon Minutes for 2014-09-23

From: <msporny@digitalbazaar.com>
Date: Tue, 23 Sep 2014 15:23:43 -0400
Message-Id: <1411500223596.0.24522@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Mary Bold and Manu Sporny for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

http://opencreds.org/minutes/2014-09-23/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
Credentials Community Group 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 and Manu Sporny
Present:
  Dave Longley, Mary Bold, Eric Korb, Bill Gebert, Manu Sporny, 
  Mark Leuba, David I. Lehn
Audio:
  http://opencreds.org/minutes/2014-09-23/audio.ogg

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: 
  https://www.w3.org/community/webpayments/wiki/UseCases#Identity
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: 
  http://lists.w3.org/Archives/Public/public-credentials/2014Sep/0018.html
Dave Longley: 
  http://lists.w3.org/Archives/Public/public-credentials/2014Sep/0019.html
Dave Longley: Manu's email: 
  http://lists.w3.org/Archives/Public/public-credentials/2014Sep/0024.html
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?
Received on Tuesday, 23 September 2014 19:24:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:21 UTC