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. ✪
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. ✪
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.
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. ✪
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. ✪
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: 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: 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. ✪
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. ✪
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: 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. ✪
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. ✪
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: 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. ✪
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. ✪
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).
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 ✪
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: 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? ✪
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 ✪
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. ✪
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: 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. ✪
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: 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? ✪
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. ✪
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. ✪
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: 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? ✪
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: 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: 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. ✪