- From: <msporny@digitalbazaar.com>
- Date: Tue, 07 Oct 2014 14:40:33 -0400
- 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