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

Credentials CG Telecon Minutes for 2014-10-07

From: <msporny@digitalbazaar.com>
Date: Tue, 07 Oct 2014 14:40:33 -0400
Message-Id: <1412707233399.0.26524@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Bailey Reutzel and Sunny Lee for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

http://opencreds.org/minutes/2014-10-07/

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-10-07

Agenda:
  http://lists.w3.org/Archives/Public/public-credentials/2014Oct/0012.html
Topics:
  1. Voting Process on Credentials Use Case Document
  2. Web Payments Agenda on CG call last week
  3. Comments on Use Cases Document
  4. Remaining Use Cases
  5. Verifiable Claims
  6. Media Rights
  7. Data Rights
  8. Proof of Pseudo-anonymity
  9. Data Rights Agreement Before Transmission of Data
  10. Access Revocation
  11. Access Audit
  12. Access Credential Audit Information
  13. Education Use Cases
  14. Access to Transcripts
  15. Online Transcript
  16. Continuing Education
  17. University Credits
  18. Bachelor's Degree
  19. Any other use cases?
Resolutions:
  1. Create and publish a preliminary Credentials Use Cases 
    document and vote on publishing it as a first public working 
    draft before W3C TPAC. Give fair notice of the vote immediately, 
    start the vote at the end of the day on Tuesday October 14th 2014 
    and keep it open for 7 days.
Organizer:
  Manu Sporny
Scribe:
  Bailey Reutzel and Sunny Lee
Present:
  Bailey Reutzel, Manu Sporny, Bill Gebert, Dave Longley, Mary 
  Bold, Tim Holborn, Mark Leuba, Sunny Lee, David I. Lehn
Audio:
  http://opencreds.org/minutes/2014-10-07/audio.ogg

Bailey Reutzel is scribing.
Manu Sporny:  We might want to add something to the agenda 
  discussion about what exactly were thinking of publishing for W3C 
  TAC status of document how we should go about vote.
Bill Gebert:  No additions to Agenda.

Topic: Voting Process on Credentials Use Case Document

Manu Sporny:  This is kinda the discussion on what were trying to 
  get done
Manu Sporny:  The discussion has to do with what were going to do 
  with use cases docuemnt. important to have  some kind of use case 
  document...so web payment group can refer to it. point to 
  document and have discussion around document and what we want to 
  do with this group
Manu Sporny:  Any comments on it being beneficial  before having 
  this document before TPAC? Or basically hold off on it?
Manu Sporny:  Trying to do is saying that the community has basic 
  agreement on these use cases. Maybe new use cases after TPAC? 
  Edit document over next 2-3 months
Manu Sporny:  Decision isn't made on call, send it out to list 
  and people can object to that proposal if they have any. Other 
  thing we need to discuss is the length of the vote?
Manu Sporny:  Usually two week affairs, the problem with that if 
  we we need to finalize some of the language today. If we delay 
  vote until next Tuesday or Friday we only have a wek for the 
  vote. could decide to do give everyone fair notice we'll have 
  vote starting at end of day next Tuesday and vote will only be 
  open till the following Tues. or Wed, Community small enough we 
  can probably do that, but fairly accelerated voting process.
Dave Longley:  Have anything in charter that says vote doesn't 
  have to last a certain time?
Dave Longley: "Within 7 days of such a request, the Chair must 
  announce the start and end dates, and the venue for the vote. 
  Such a vote must be open at least 7 days and should be no more 
  than 14 days, using a structured online voting solution, ensuring 
  that no member votes more than once."
Manu Sporny:  Vote must be open at least 7 days and no more than 
  14 days.
Dave Longley: http://www.w3.org/community/credentials/charter/
Manu Sporny:  We're really  not required to do that. Could do 
  that based on working consensus.
Manu Sporny:  Proposal create a publish a preliminary use cases 
  document. Before W3C TPAC. Start the vote at end of day on 
  Tuesday, October 14.

PROPOSAL:  Create and publish a preliminary Credentials Use Cases 
  document and vote on publishing it as a first public working 
  draft before W3C TPAC. Give fair notice of the vote immediately, 
  start the vote at the end of the day on Tuesday October 14th 2014 
  and keep it open for 7 days.

Dave Longley: +1
Manu Sporny: +1
Bailey Reutzel: +1
David I. Lehn: +1
Bailey Reutzel: Mary: +1
Bailey Reutzel: Mark +1
Bailey Reutzel: Bill: +1
Tim Holborn: +1

RESOLUTION: Create and publish a preliminary Credentials Use 
  Cases document and vote on publishing it as a first public 
  working draft before W3C TPAC. Give fair notice of the vote 
  immediately, start the vote at the end of the day on Tuesday 
  October 14th 2014 and keep it open for 7 days.

Manu Sporny:  Purpose of call is to try and get preliminary set 
  of use cases in document. Don't have to be perfect but should be 
  fairly clear in what we're trying to address.
Manu Sporny:  Let's talk about W3C's response to the agenda 
  bashing we did on web payments call.

Topic: Web Payments Agenda on CG call last week

Manu Sporny: https://web-payments.org/minutes/2014-10-01/#8
Manu Sporny: That was the discussion ^^
Manu Sporny: This is the preliminary Agenda: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Oct/0013.html
Manu Sporny: Direct link to preliminary agenda: 
  https://docs.google.com/document/d/1R_hLcUBXJxm3DhQC4JmyzS_hKlnhQDUFBvfZR5UaFf0/edit?usp=sharing
Manu Sporny:  Keep in mind that this is a proposal by web payment 
  community group to the web payment activity...suggestion on what 
  we'd like to see discussed.
Manu Sporny:  General layout morning meeting on web payments... 
  finish off day with web payment meetin gon monday and tuesday. On 
  wednesday do a wrap-up discussion to those that couldn't make the 
  meetings. Credentials meetings sandwiched in between.
Manu Sporny:  Staff contact said that they're working on agenda 
  w/ chairs, fairly dismissive of CG's comments on Agenda.
Manu Sporny:  Staff contact and chairs have been unresponsive 
  since last Friday. Maybe because they're busy but getting 
  concerned there will be miscommunication leading up to TPAC
Manu Sporny:  Fair notice on agenda and whats being discussed.
Manu Sporny:  Staff contact not releasing agenda until next week 
  . gives poepl only a week or a week and a half of prep time.
Manu Sporny:  This is problematic. He also said this premature 
  that we have a Credentials CG meeting at all.
Manu Sporny:  Unfortunate reality here is that staff contact 
  hasnt been tracking CG work, and all credentials calls weve been 
  having, and understand many payments co's raised credentials 
  questions.
Manu Sporny:  We'll have to lobby them pretty heavily when they 
  make that agenda public to make sure we can talk about 
  credentials.
Manu Sporny:  Clearly not happy about approach they're taking. 
  Done between three people instead of having the communities 
  involved. I understand the pressure they're under, but this is 
  fairly bad form when it comes to open standards, not even Web 
  Payments Workshop attendees are in on discussion. 
Manu Sporny:  Any thoughts on this?
Mary Bold:  Direct communication with staffer? Anything we need 
  to do or record? Doesnt sound like this is something you like to 
  complain about but we need to keep persisting to make the case?
Tim Holborn: W3C has initiated a program entitled ‘webizen’ which 
  is an individual membership, for W3c (of forms).  This is an 
  excellent example around why this type of membership category is 
  important to the W3C
Manu Sporny:  Communtiy groups dont have much say with whats 
  going on. Have W3C members participate in this call though... 
  Fed. Reserve, Yandex, Dont wan to invoke those orgs names... but 
  i think staff contact is unaware that W3C member shaving these  
  discussions.
Manu Sporny:  All we can do is continue to lobby them. If there 
  are W3C memebrs that care about this they should individually 
  lobby the W3C to ask them why the agenda planning isn't being 
  done publicly.
Mary Bold:  Restriction only been communicated to the staff 
  member to you?
Manu Sporny:  Yes.
Mary Bold:  Hard to respond when there's no notice.
Manu Sporny:  Yea.
Tim Holborn: Suggestion: lobby for improvements via webizen 
  program
Manu Sporny:  Not much we can do than say where's the agenda. 
  That might trigger well we're working on it internally and then 
  we can ask why
Mary Bold:  We'd like to propose something
Manu Sporny:  Worse case they will propose agenda at end of next 
  week and be a rush to make sure CG is heard on that agenda.
Tim Holborn: FYI: 
  http://lists.w3.org/Archives/Public/public-webizen/2014Oct/0002.html
Manu Sporny:  Try and keep pressure on the staff contact and 
  chairs to respond. Asked them about this last Friday and still no 
  response.
Clarification: Manu received a response one hour after this 
  Credentials CG call and the is ongoing discussion wrt. resolving 
  this issue.
Manu Sporny:  Anything else on this agenda item?

Topic: Comments on Use Cases Document

Manu Sporny: http://opencreds.org/specs/source/use-cases/
Manu Sporny:  Very preliminary very drafty use cases document 
  posted on website.
Manu Sporny:  What got in there now are web payment use cases 
  that got into there over last two weeks.
Manu Sporny:  Gotten some great feedback already. During the call 
  today working on extending those use cases based on Tim and Mark 
  Luba's comments they sent in.
Manu Sporny:  Of course doing some general comments on document.
Manu Sporny:  Any concerns on document or how its put together? 
  One piece of feedback... Something we might want to do is in this 
  template we have for describing the use cases we might want to 
  describe in a more general way. State in very generic way and 
  then state an example that might be more helpful.
Manu Sporny:  Great proposal and we should definitely do that.
Manu Sporny:  Other comments?
Manu Sporny:  One other comment still a bit to payments specific.
Manu Sporny:  Try and make these even less specific and move the 
  payments specific details into a sub-section.

Topic: Remaining Use Cases

Manu Sporny: 
  http://lists.w3.org/Archives/Public/public-credentials/2014Oct/0010.html
Manu Sporny:  There are two emails we need to go over. First from 
  Nate Otto. Nate brought up that likes composaility mechanism but 
  there is one particular use case thats interesting allowing two 
  disparate systems to link up with each other based on shared
Manu Sporny:  Both systems have person's social security number 
  use that number to sync between each other. Or email address or 
  drivers license identifiier.
Manu Sporny: Potential use case: Enable credentials to be issued 
  by systems in a way that allows each
Manu Sporny: System to align their internal identifiers with the 
  other.
Manu Sporny:  Any thoughts on that use case?
Dave Longley:  To me thats generally supported by the design in 
  using JSON LD,
Dave Longley:  Both systems understand government ID and data 
  matches then you're talking about same identity.
Manu Sporny:  Question is if we want to put this use case in the 
  document?
Dave Longley:  Maybe this should be design criteria to enable 
  things like this to happen?
Manu Sporny:  Kinda like identifier alignment use case.
Manu Sporny:  We are going to have universal idenitifier  
  associated with these credentials.Do the legacy systems need to 
  use this universal identifier? That's probably not an assumption 
  we should make. Fall back to this design criteria.
Dave Longley:  Right
Manu Sporny:  Largely an argument for legacy systems
Manu Sporny: Ok so we have this - Design Criteria: Enable 
  credentials to be issued by systems in a way that allows each 
  system to align their internal identifiers with the other.
Manu Sporny:  No objections.
Manu Sporny: Ok, so let's move on to this: 
  http://lists.w3.org/Archives/Public/public-credentials/2014Oct/0014.html

Topic: Verifiable Claims

Manu Sporny: Tim wanted a credential use case for this: Existing 
  proof of patent -  I have a patent or trademark.  I offer the use 
  of this patent or trademark subject to “this” agreement.
Manu Sporny:  Use that patent or trademark based on certain type 
  of license.
Manu Sporny:  Prove to me that you have X qualification. Most 
  basic use case, but don't call it out explicitly, but we probably 
  should.
Manu Sporny: The proposal is to have a basic Proof use case: An 
  entity would like to prove that they have a particular 
  qualification, achievement, or quality that has been vouched for 
  and digitally signed by a 3rd party.
Manu Sporny:  Should we have proof use case?
Dave Longley:  Had some discussion on a previous call. One issue 
  is just the language. Proof has some issues Eric brought up. Way 
  this is written you could actually prove, that you've achieved 
  something which is different than a third party said you have 
  achieved something. Need some better language here.
Dave Longley:  Eric specifically said he wanted to not use the 
  word proof, but maybe claim instead.
Manu Sporny:  Digitally verifiable credentials... This is the 
  Know Your Customer thing. There is some overlap.
Manu Sporny:  But not enough to be merged into one.
Manu Sporny:  Do we have use case with the proof/claim thing.
Dave Longley:  I think we need to specifically state it but 
  worried about the language.
Manu Sporny:  Use case could be called third party claims.
Dave Longley: "An entity can demonstrate that a 3rd party has 
  asserted that they have a particular qualification, achievement, 
  or quality."
Manu Sporny: An entity would like to prove that a 3rd party has 
  made a particular set of claims about them (such as a 
  qualification, achievement, or quality). The claim should be 
  verifiable.
Manu Sporny:  Should we split verifiable thing out? And then how 
  is it actual proof?
Dave Longley:  No Has to be verifiable to eb part of use case.
Manu Sporny:  Any comments on which one they like more? Or 
  another proposal?
Manu Sporny: An entity can demonstrate that a 3rd party has 
  claimed that they have a particular qualification, achievement, 
  or quality. The claims should be verifiable.
Dave Longley:  Problem is still that...still has confusion that 
  makes people think you can go verify that the claims are true, 
  instead of that the claims were made.
Dave Longley: "An agent can verify that a 3rd party has made a 
  particular set of claims about an entity (such as a 
  qualification, achievement, or quality)."
Manu Sporny: An entity can demonstrate that a 3rd party has 
  claimed that they have a particular qualification, achievement, 
  or quality to a requestor. The requestor should be able to verify 
  that the claims were made by the 3rd party.
Dave Longley:  Almost like we need another party in here... Agent 
  or something in here to verify that those claims were made.
Manu Sporny:  Issuer, credentialee and requestor
Dave Longley: "A requestor can verify that an issuer has made a 
  particular set of claims about an entity (such as a 
  qualification, achievement, or quality)."
Dave Longley: "A requestor can (cryptographically) verify that an 
  issuer has made a particular set of claims about an entity (such 
  as a qualification, achievement, or quality)."
Mark Leuba:  Question please? Thinking about a student...the 
  requestor can they independently address the issuer without some 
  kind of pre-approval from entity that is asserting the 
  qualifications?
Manu Sporny:  It can be.
Manu Sporny:  University could directly pull students info from 
  the testing center is they have an agreement to do that. 
  Potentially violates laws in some parts of the world, but the 
  tech can allow that to happen.
Mark Leuba:  Some delegation of authority?
Manu Sporny:  We're definitely not saying a university can get 
  access to student transcript from another university without any 
  authorization from the student or going around the laws that 
  exist today for those cases.
Mark Leuba:  And there will be tool, mechanism...that would allow 
  for that delegation to occur.
Manu Sporny:  Yes

USE CASE: A requestor can (cryptographically) verify that an 
  issuer has made a particular set of claims about an entity (such 
  as a qualification, achievement, or quality).

Dave Longley: +1
Manu Sporny:  Anything else before we move on?

Topic: Media Rights

Manu Sporny: Tim said: CREATIVE COMMONS (MEDIA) I offer this 
  content freely for civic use.  If you seek to print this photo, 
  then i charge you $2 amount / Value. (take to printer, printer 
  software sees credential  / claim, charges customer for print + 
  fee / cost).
Manu Sporny:  If your name is John Smith it'd be a very 
  particular J. Smith associated with the copyrgiht.
Manu Sporny:  That part seems to be payments use case.
Manu Sporny:  Given the prvious use case, i think we have this 
  one covered. Any thoughts?
Dave Longley:  This is just an example in sub-section. I'm in 
  agreement

Topic: Data Rights

Sunny Lee is scribing.
Manu Sporny:  Next up, we have data rights
Manu Sporny: Tim says: How do we protect the person before they 
  send their credentials?
Manu Sporny:  Tim is saying, how do we protect the person before 
  they send in their credentials
Manu Sporny: For example - I need to receive a credential from a 
  trusted authority that you keep to your data agreements. ie: 
  anti-malware company xyz actively scans websites to identify what 
  tracking data they’re using on the relevant pages, generating RDF 
  about these website behaviours as a means to provide arbitration 
  capabilities surrounding the use of credentials for payments or 
  other purpose.
Manu Sporny:  Basically an org wants to say that you are a 
  trustworthy org. Like a better Business bureau seal on the 
  website. Thinks this use case is already covered by the basic 
  credential use case and the verifiability use case.
Manu Sporny:  Does anyone think this hasn't been covered already?
Dave Longley:   Think Tim was referring to making assertions when 
  sending credentials to places.
Manu Sporny:  That's covered in another one. If Tim is referring 
  to that, we have a data rights use case covered in another design 
  document.
Dave Longley:  I think we have got this covered. Should figure 
  out where this example should go.
Dave Longley:  Think Tim was partially get at the idea of 
  creating a system that could automatically assert that certain 
  companies can be trusted with your data. You can know that 
  company will comply with that.
Manu Sporny:  Think this use case is covered.

Topic: Proof of Pseudo-anonymity

Manu Sporny: Tim said: If the website claims a type of 
  pseudo-anonymity is provided by the site; this is verified by the 
  anti-malware organisation, who counter-signs the credential at 
  the time of transmission; therein reinforcing a position of trust 
  for the merchant through a trusted 3rd party.
Manu Sporny:  Basically means that the customer trusts some 3rd 
  party, say google, and merchant trusts 3rd party, say google, 
  customer would like to say merchant is providing pseudo anonymous 
  transaction. They'll try to crack who you are.
Manu Sporny:  Some kind of claim being made by a 3rd party. 
  Merchant has pseudo anonymous transcaction claim. Customer that 
  wants to make a purchase is going to ask, that that credential is 
  counter signed by google before they do that transaction. Like 2 
  signs of that credential.
Manu Sporny:  Think this might be covered via composibility use 
  case.
Manu Sporny:  Or we use endorsement where merchant continuously 
  endorses the pseudo anonymous credential, google resigns it every 
  single hour and give it to the buyer to prove it's an up to date 
  credential
Manu Sporny:  Or it can be re-issued every hour by google and the 
  bank.
Manu Sporny:  Any other thoughts on this use case?
Dave Longley:  Thumbsup

Topic: Data Rights Agreement Before Transmission of Data

Manu Sporny: Tim said: I agree to providing you this information 
  on the following terms  Terms are stipulated using RDF (some form 
  of linked-data) and that these terms be agreed to prior to 
  transmission of payload data.
Manu Sporny:  This use case says that a credential that you send 
  to requestor, the requestor needs to agree to certain data rights 
  agreement. Say, I'm going to send you my driver's license but you 
  have to agree you're not going to send any of my info before I 
  send it to you.
Manu Sporny:  After agreement, credentialee sends credential. 
  Falls into data rights.
Manu Sporny:  Any thoughts on this? What we can do today is we 
  can ship off credential and attach a bunch of metadata like 
  saying you can't use this for advertisement.
Dave Longley:  Initial thought is that this is out of scope
Dave Longley:  You can ask for one or more potential agreeements. 
  Will the two documents be linked so that they're inseparable?
Manu Sporny:  They can be using linked data but that's a big 
  question mark. What's the term of the agreement? I think that's 
  what Dave means, wrt lots of things to consider.
Manu Sporny:  For example requestor may have intended agreement 
  to only apply to driver's license, not email or other data.
Dave Longley:  Sending information over to them and getting 
  signature saying this is the only way they'll use it requires 
  another round trip.
Mark Leuba:  A lot of chasing around of proof that there was in 
  fact this commitment
Mark Leuba:  From long term liability perspective, having an 
  implied constraint in the request as to the use of the material 
  is very importnat. Having that request and constraint is part and 
  parcel to the actual credential is valuable.
Dave Longley:  Trying to say how to ensure the data is linked. 
  The requestor specification's information can be included. 
  Requestor's original statement on how they would use the 
  credential and signature could be used without round trip
Manu Sporny:  First step of requesting a credential is these are 
  the properties that I want to konw about you. Included is I 
  promise not to use your info for advertisement purposes and 
  here's my signature.
Manu Sporny:  Identity provides adds all those claims in there 
  and adds claim that they won't use it for advertisement purposes, 
  digitally signs it as a bundle and sends it back
Mark Leuba:  Has all the components of a contract in here.
Dave Longley:  We would need to look into whether we want to say 
  your signature needs to be on it as well
Mark Leuba:  Or a link to the 3rd party.
Dave Longley:  We would have to start saying person that provides 
  the credential must countersign the 3rd party
Dave Longley:  Even if there is no data right agreement. Your 
  signature still needs to exist on there. Needs to be a part of 
  the protocol.
Manu Sporny:  This does allow another layer of complexity. Saying 
  there needs to be 2 signatures. We don't want these credentials 
  to be copied and used.
Dave Longley:  You do place your signature on a message. For 
  secure messaging procotol. This includes the domain that the 
  credential is intended for.
Manu Sporny:  Short time frame that that credential is valid for.
Dave Longley:  Data rights agreement needs to persist longer than 
  the 5 minutes.
Manu Sporny:  With all that said, we have a solid solution that 
  fits with the current architecture. How does use case document 
  change based on this discussion. This is prior transmission of 
  payload data.
Manu Sporny:  We're getting into digital contract stuff which is 
  great for web payment use cases but question is do we need this 
  for credentials use case as well? Are there serious legal and 
  business reasons to do this?
Dave Longley:  One of the other things we can build into this is 
  if you're requesting a credential could have a linked data 
  property that if this credential is given to anyone else, needs 
  to have a signature from the owner.
Mark Leuba:  Think this is a great idea.
Dave Longley:  We can do this more complicated digital contract 
  stuff in version 2 or at least have design criteria on how it can 
  be implemented in this version.
Dave Longley:  We want to ensure that a countersign is required 
  if someone wants to use it.
Dave Longley:  Requiring a credential to be signed by 
  credentialee such that a requestor can transmit a data rights 
  agreement that can be bundled with a credential that the 
  credentialee grants them access to
Manu Sporny: Design Criteria: Support the idea of requiring a 
  credential to be signed by the credentilee such that a requestor 
  can transmit a data rights agreement that can be bundled with any 
  credential that the credentilee grants them access to
Dave Longley:  And the thing that's important is that we have a 
  mechanism built in that a credential requires this when giving it 
  to a requstor. That way you can know ahead of time, whether you 
  need to see a data rights agreement or a signature from the 
  credentialee to know you're not violating the agreement
Dave Longley:  I think we should have this in there and say we 
  should allow this to happen in the future. We should keep this in 
  mind so future versions can use this idea easily with the 
  existing version of what we've got.
Manu Sporny:  We'll put this in the doc with the caveat that the 
  language isn't complete but that we're thinking about this.

Topic: Access Revocation

Manu Sporny: Tim said: I have reason to believe you’ve broken 
  your terms and i seek to rescind access - how is that supported?

USE CASE: Access Revocation - Pre-authorized access to 
  credentials may be revoked at any time by the credentilee.

Manu Sporny:  We have preauthorization use case but don't have 
  mechanism where we revoke that access. So the use case is access 
  revocation, pre-authorized access can be revoked anytime by 
  credentialee?
Dave Longley:  Doesn't this fall under access control list? What 
  part of standard does this need to be a part of?
Manu Sporny:  It is something that only a credential that a vault 
  or identiy provider will implement but will be good to have in 
  the doc that this exists.
Dave Longley:  This should be a design criteria to ensure these 
  things could be implemented by credential vaults or identity 
  providers
Dave Longley:  It's another one of the value add for services.
Manu Sporny:  Is the preauth use case one of those too?
Dave Longley:  Thought it was originally.
Manu Sporny:  Access control list would be a design criteria and 
  preauth will move over to design criteria
Dave Longley:  Yes
Dave Longley:  There is a component that goes into the standard 
  but having access control list and implementation details don't 
  actually go in standard.
Manu Sporny:  We need to have a use case stick around but ACL and 
  preauth be design criteria
Dave Longley:  In essense preauth is a use case but it's really 
  about being able to access after pre auth has happened, in terms 
  of where tech is concerned
Dave Longley:  You should have preauth language in there 
  somewhere because someone will bring it up

USE CASE: Non-interactive Credential Transmission - Ability for 
  requestors to request pre-authorized access to a credential 
  through a non-interactive channel.

Dave Longley: "Ability for requestors to request credentials that 
  they have been pre-authorized to access through a non-interactive 
  channel."
Manu Sporny:  In general we'll move ACL and permissions to design 
  criteria and that's something vaults and identity provides as 
  value add
Dave Longley:  We can say this is optional. That identity 
  providers don't have to provide this.
Manu Sporny:  Any thoughts on access revocation, ACL, etc?
Manu Sporny:  Use case we want to have is that identity providers 
  have ability to request credentials they've been pre-authorized 
  to access through non interactive channels.
Manu Sporny: Tim also said: I have the right to change my mind 
  (in certain instances)
Manu Sporny: Tim also said: I have the right to revokation of 
  access to my data

Topic: Access Audit

Manu Sporny: That's all ACL stuff, we already have it for a 
  design criteria. 
Manu Sporny:  In general right to change my mind, right to revoke 
  is all access control related. We've got this covered.

Topic: Access Credential Audit Information

Manu Sporny: Tim said: I would like to audit who has access to 
  what data
Manu Sporny: This is a facility that doesn't need to be 
  standardized, the identity provider could expose this feature in 
  interesting ways as a competitive advantage.
Manu Sporny:  Think this is a facility that we don'tn need to 
  standardize, this is a value add that an id provider or 
  credential service can provide.
Dave Longley:  Agree.
Manu Sporny:  Any other comments?
Manu Sporny:  Who is tracking me is a not specific to credentials
Manu Sporny: Tim also said: I want to store a copy of any data 
  relating to me with respect to the use of this credential, on a 
  service that is available to me.
Dave Longley:  My read is if someone associates data with 
  credentials, want to see what that data is. Think this is out of 
  scope. Can see how this is interesting. This isn'tn enforceble by 
  a technical standard.
Manu Sporny:  Agree this is out of scope.
Manu Sporny: Tim said: Provider of these services declares it 
  will not be providing you a copy of this information pertaining 
  to you.   I would therefore like a record of this declaration as 
  a constituent of providing my details.
Dave Longley:  If you go visit a website and give them your creds 
  the website will store some info about you related to that cred 
  that you don't have access to, he would like the website would 
  like to make a declaration so you can have access to it. If a g+ 
  service asks for a different email address, google stores a bunch 
  of info related to that email, google stores that info and says 
  we're storing this info related to that email, is tha
Manu Sporny:  Don't know why we need to support this.
Dave Longley:  This might be a complicated data rights 
  agreements.
Dave Longley:  Companies can make that declaration using design 
  we discussed earlier for the future.
Manu Sporny:  Does anyone feel strongly about putting this in use 
  cases doc? Would like to get more info from Tim.
Manu Sporny:  Think Dave you're right but feels vague and 
  complex. Doesn't feel version 1. Let him object on why not to put 
  in use case doc.

Topic: Education Use Cases

Mark Leuba:  This represents a process that is very standard in 
  education these days. In paper, pdf world.
Mark Leuba:  Exchanging data that goes against where we are with 
  rdf and linked data and the possiblity of a more elegant way of 
  sharing data.
Mark Leuba:  Main reason for being a part of committee is trying 
  to put this out there that in some future point, by adding these 
  design criteria that some process like this can be realized.
Manu Sporny:  We want to say something really general but then 
  get more detailed about supporting specific use cases.
Manu Sporny: So, Mark Leuba starts off: Louisa is a college 
  student who has completed her first two years at Central 
  Community College and wants to transfer to a four year university 
  to continue her bachelor’s degree in accounting.  Louisa is also 
  in the job market and wants her future employers to see the types 
  of courses and skills she has learned.
Manu Sporny:  Start off by grounding set of use cases with 
  persona Luisa.

Topic: Access to Transcripts

Manu Sporny: Mark says: Louisa has applied to two colleges and 
  she wants to provide access to her transcripts from CCC to these 
  new colleges to satisfy their prerequisite requirements.
Manu Sporny:  This can be covered by pre auth and ACL, non 
  interactive one and the transmission use cases.
Manu Sporny:  Any disagreement that we don't have this covered in 
  the spec including changes we've talked about today?
No disagreement.
Manu Sporny: Next up, Mark says: Louisa also recently applied for 
  a job as a billing analyst at NewCo and she wants to share her 
  transcript and some of her school projects with the interview 
  team members to showcase her accounting, leadership and 
  communication skills.
Transmission, pre auth, Access control use case
We got it covered.
Mark Leuba:  It would be great if there was a mechanism to expose 
  to a limited group access for a specified time, my personal 
  container of docs or work products that I've created. Key here is 
  that it's authorized by me, there's a defined time frame and it's 
  authorized to a specific collection of individuals.
Dave Longley:  What we're standardizing will include all this. 
  The specifis are out of scope.
Mark Leuba:  See that and agree.

Topic: Online Transcript

Manu Sporny: Mark also says: Rather than send paper or physical 
  copies via email, Louisa provides secure, limited access to her 
  transcript and online portfolio to the college admissions 
  department and to the NewCo HR department.
Manu Sporny:  Again access control, transmission use case.
Manu Sporny:  This this is covered.
Dave Longley:  No disagreement

Topic: Continuing Education

Manu Sporny: Mark says: Louisa got the job at NewCo and is doing 
  very well, taking advantage of NewCo’s well-known professional 
  development program by taking several “learn at lunch” courses 
  and receiving continuing education units toward a certificate in 
  accounting.
Manu Sporny:  Believe this is covered by storage, base credential 
  and verifiability use cases. Issuer is either the company doing 
  the lunch courses or her company. They can dump that into 
  identity provider.
Manu Sporny:  Any disagreement that we don't already have this 
  covered?
No disagreement.

Topic: University Credits

Manu Sporny: Mark said: In the fall, Louisa started at 
  Achievement University and begins taking courses.  As Louisa 
  finishes courses the credit is accumulatedon her AU transcript.
Manu Sporny:  Question for Mark, is internal system issuing 
  credential to Louisa internally?
Manu Sporny:  Or they can issue wherever Louisa's identity 
  provider. Is a credential actually being issued or not?
Mark Leuba:  She hasn't earned her bachelor's degree yet.
Mark Leuba:  Ed industry is going through a lot of change to 
  competency based credits. Me as Louisa wants to ask my school for 
  a copy of a transcript.
Mark Leuba:  Maybe there are 2 or 3 of these that are related to 
  a new job. Pursuing my degree. Here's some coursework related to 
  those. A work in progress but still same motivation exists to be 
  able to share. Below the degree level at this point.
Manu Sporny:  Tech supports microcredentialing.
Manu Sporny:  There's no limit to that. How is the org want to 
  issue their credentials whether micro or macro.
Manu Sporny:  Final use case

Topic: Bachelor's Degree

Manu Sporny: Mark said: When finally Louisa receives her 
  bachelor’s degree, she has accumulated academic credentials at 
  two accredited colleges and professional credits at her employer. 
     Her college and work experience have really complemented each 
  other and now Louisa has the confidence to pursue her Certified 
  Public Accountancy.   As part of Louisa’s application to the CPA 
  program in Exemplar University’s School of International 
  Business, she grants secure, 
Manu Sporny: Limited access to her transcripts and portfolio at 
  CCC, AU and NewCo to the Exemplar admissions officer for 
  consideration.
Mark Leuba:  This is where we're linking other credentials or 
  simply collecting them into a container of credentials for the 
  convience of the recipient. Here's my comm college transcript, 
  here's my undergrad transcript, work products. Collecting 
  everything as part of say application for grad school.
Manu Sporny:  This is really about credential bundling?
Dave Longley:  We don't need to see it as credential bundling but 
  rather a request for several different credentials.

Topic: Any other use cases?

Manu Sporny:  There were 2 use cases that I added to doc based on 
  US fed reserve comments.
Manu Sporny: 
  http://opencreds.org/specs/source/use-cases/#endorsements
Manu Sporny:  Those have to do with endorsements. The ability to 
  endorse, countersign a credential and the ability to have 
  multiple signatures. Chain of signatures that are not dependent 
  on one another.
Manu Sporny:  Composibility was another one Nate said he liked.
Manu Sporny:  Are there any other use cases that should be in 
  here that we may have missed? Sunny, are we covering what Badge 
  Alliance needs out of these use cases?
Sunny Lee:  Yes, Badge Alliance use cases should be covered by 
  what you have so far. [scribe assist by Manu Sporny]
Dave Longley:  We can always add more as needed. We've got a 
  pretty good chunk for upcoming meeting at TPAC.
Manu Sporny:  With that we'll shove as much of these changes into 
  the doc. We'll send out for review on mailing list. We'll have 
  another call next week to make sure this contains everything. 
  Will start voting after next week.
Manu Sporny:  Anything else?
David I. Lehn: Nope.
Manu Sporny:  Thanks to everyone! We'll get this document prepped 
  and ready for a vote next week.
Received on Tuesday, 7 October 2014 18:40:58 UTC

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