Manu Sporny: Exec summary document - not much changed since last invitation from Manu. Added a statement on Accessibility, and is required by W3C. We will start circulating very soon. ✪
Manu Sporny: Any concerns about the Executive Summary or the proposal to circulate it among W3C memberships. ✪
elf Pavlik: When we will have [LINK TO SUPPORT FORM] available? ✪
Manu Sporny: The statement says the standard must take Accessibility into account, not to prevent the use of the technology by people with disabilities. ✪
Brent Shambaugh: Is that related to Linked Data? ✪
Manu Sporny: For LD, it would indicate that brail support must be available. This comes out in the Use Cases, for example to demonstrate how a person that cannot see can receive and have access to that credential. For example, we couldn't say use of Biometric Fingerprints is required. ✪
Dave Longley: I have been adding comments about useabilty to describe suitiability. ✪
Manu Sporny: Wondering if the word suitability is known, Dave: i tried to elaborate; Brent: Where would gym membership or a marriage license fit? Dave: Under workplace, or civil society or identity. ✪
Manu Sporny: We won't cover everything in the summary, just a range of the types of things. ✪
Manu Sporny: Other comments on Exec summary? Elf: When will we have a support form for people to support the work? ✪
Manu Sporny: We need to create links to the support form, the charter, and the use cases. When they are done we will circulate Exec Summary. ✪
Manu Sporny: The use cases will take a couple more weeks to get done. But we can circulate this with orgs we have a good relationship with to give them a heads up. ✪
Manu Sporny: Elf, we need to fill out the support links before broad distribution. Manu: I will take the links. ✪
Adrian Hope-Bailie: Would we consider the use cases for ownership as important in this work? As opposed to asserting a skill or age. e.g. I own a page, . Manu: You have raised an important point. We have not been explicit, ✪
Adrian Hope-Bailie: Generally people express ownership by holding a key but agents may hold the key on their behalf. Even traditional bank accounts or self trading...Manu: would you add? Adrian: Yes. ✪
Topic: Use Cases
Manu Sporny: Next topic - Use cases. Last document needed to "get into shape". ✪
Manu Sporny: Sunny, Carie and Nate have been working on this, reorganizing. Thank you. Last week I proposed a micro-use case approach. It's the same as being used by Web Payments user group. It made our progress faster. ✪
elf Pavlik: In "Credential or just a Statement?" I try to exercise view that we can pretty much make Credential out of any set of LD statements, so as long as one can create linked data for ownership, marriage, you name it it can also become a Credential. https://lists.w3.org/Archives/Public/public-credentials/2015Mar/0007.html✪
Manu Sporny: Here is a link to the example. Please look at the Table of Contents for the proposed document structure. Starts with high level introduction, what is a credential, why is it important, how are they used... ✪
Victoriano Giralt: I wanted to say, that I have perused the micro-usecases documents and really like the approach ✪
Manu Sporny: Description of the problem, etc. Next is a high level introduction to the Live Cycle of a credential, the phased-based approach. What are the phases of what you do. With credentials it did not work out very well. More straightforward with web payments. ✪
Nate Otto: Sorry all, just joining now. Yeah, I think we noticed with the previous approach that the "phases" overlapped more with credentials than they did with something like commerce. ✪
Manu Sporny: Instead of phase-base approach, I tried a LIfe Cycle, the issuing/earning aspect of it. e.g. we have these credentials you can earn, then you can earn and the issuer issues it. The next stage is when an organizations asks for the credential, the Consumption part. ✪
Manu Sporny: This is my attempt to demonstrate how we can talk about credentials based on a life cycle, with predefined steps and substeps. ✪
Manu Sporny: E.g. first step an issuer advertises, recipient earns, issuer issues, organization consumes... let me stop there. Is this the right way to look at this? Any comments? ✪
Nate Otto: How can we convey when steps might be skipped in this format? ✪
Dave Longley: Quick comment, looking at the payments document, there is only one thing to model, the payment transaction. I think we have the same with credentials but we have multiple boxes, each step breaks down into multiple phases. There are more things to be modeled. ✪
Dave Longley: If you look at each step as we do with the payment transaction, we have more steps to document. ✪
Manu Sporny: Elf asked a question (above). Dave: we will cover that. Victoriano: I like the approach. Nate: how to convey when steps can be skipped? Manu: There is a section "in the real world", in those scenarios we specifically write the step and say "this step is skipped". ✪
Brent Shambaugh: From the UC's it looks like you are trying to standardize the protocol. Manu: in general, W3C focuses on prototcols and data formats. Lower level protocols, the W3C will move the protocol to the IETF. Your observation is right. We are talking about protocol and data formats. ✪
Brent Shambaugh: Do you have an ontology? Manu: that is what Nate, Sunny, Kerri are working on. Yes, we are looking at Open Badges and Credentials ontology. Brent: the use cases are how you use that in a way. ✪
Kerri Lemoie: Breaking it down in this format is nice and clear. Slight concern about calling referencing it as lifecycle. Not sure of a replacement term.... ✪
Manu Sporny: The UC's should be generic, not talk about specific technologies. More what world we want to see. The WG's develop the technologies to meet the requirements. ✪
elf Pavlik: We have vocab topic at the end of today's agenda, I hope dlongley and NateOtto can also summarize our yesterday call ✪
Manu Sporny: Any other questions? Kerri: concerns about the term Life Cycle, Manu: Agree, if we can think of a better term. Dave: Agree, it indicates credentials may expire. I think we can use the phase terminology but we need a word for what sits above phases. ✪
Dave Longley: We have multiple questions, how to you issue, how do you consume, we just need a high level term above phases. ✪
Manu Sporny: Agreed. Any other thoughts? Nate: In the Consuming phase I left a comment, not all credential sharing will share in that work. Maybe we can write a dedicated phase for special cases. or we can substitute steps as opposed to leaving one out. ✪
Manu Sporny: The structure still needs work, this is a first pass. I agree with you Nate. Especially the consuming case, middle of p3. Starts with credential consumer request. Maybe we skip the first step and recipient pushes the credential. ✪
Sunny Lee: Sort of feels like we're doing use cases all over again from scratch... ✪
Manu Sporny: We can handle this different ways. In the payment group we tried this but there are 30-40 different flows, we couild approach this, 10-15 flows at least. I think the right approach is phases/steps with some steps that can be skipped. We won't know without trying more. Nate agree? ✪
Nate Otto: I think it is a matter of massaging the format, providing alternate flows. ✪
Nate Otto: Did you look at the old document? Manu: Yes, I copy/pasted and the portions will just go into different places. Sunny are you on audio? : ✪
Manu Sporny: I heard it feels like we doing UC all over again from scratch, that we are trying to fit into payments model rather than something that fits the Credentials work. Manu: Sunny is that right? Sunny: Yes ✪
Manu Sporny: Very valid points Sunny. This is an experimental document, not decided by the group. To address some of your concerns, we will use 80% of content from previous document. I don't think we will lose the hard work from the original document. ✪
Manu Sporny: If we do lose content and it is redundant, that is a good thing. Or if we lose things we need that will be bad and indicate we don't have the structure right yet. If we can save the work from the other document we should be in pretty good shape. ✪
Nate Otto: Manu, can you summarize why you think this format is better in one sentence? Is it designed to appeal to a particular type of user at the W3C, for instance? ✪
Manu Sporny: Other thoughts? Should we stay with the current UC document? Dave: I am in favor of reorganizing, makes it easier to use and organize. We can call it a Credential Framework/with Operations and Phases. ✪
Manu Sporny: I see you have made edits to the documents. Dave: yes to show how we can model it. ✪
Victoriano Giralt: +1 To the doc and operations and phases, I do not know why but framework does string a chord with me ✪
Nate Otto: +1 To "operations", which feels like it's at the right scale to have 4-5 steps. ✪
Manu Sporny: We stopped at the high level intro. Sunny I hope this speaks to your concerns. If you look at p1, a simple example of a credential. The idea is to start with intro, basic framework, a simple example. e.g. recipient receives and stores. Organization consumes, to ground how these phases work in the real world. Just one example. Then we talk about the framework in detail, this is where the UC's come in. ✪
Victoriano Giralt: May be stupid but it came to my mind: "credential minting process" with operations and steps? ✪
Dave Longley: To me, "credential minting process" only seems to cover the issuing of credentials, not their consumption (to go with the analogy, minting a currency doesn't really include actually using it to exchange for goods/serviecs) ✪
Manu Sporny: This is the first "micro use case", composed of fairly simple, broad category, specify the motivation. Look at bottom of p4, where recipient earns credential. Bottom of p6, top of p5. For example micro use case Testing. ✪
Manu Sporny: Easy for people to grasp. Top of p5, you can earn a credential by an action, .eg attended a conference, a real world action. At its elemental level, these micro uc's are supposed to be very simple. ✪
Manu Sporny: Can be verbose as well, bottom of p5, a claims micro-use case. Issuer can make a veriety of claims against a recipient, online course, driver's license, examples. But rest of the format stays the same, p5 point out security implications to verify who they are. Privacy implications, we must protect PII. ✪
Manu Sporny: This is an example of a verbose micro-use case. All this text came from the current document. My hope is all UC's will migrate over. Sunny, will that address your concern? ✪
Manu Sporny: Only 7 minutes left. Can we put this on hold unless anyone disagrees. We will try to move all content into this experimental one to test it and we will discuss next week and if all are ok we can move on.. ✪
elf Pavlik: In "Credential or just a Statement?" I try to exercise view that we can pretty much make Credential out of any set of LD statements, so as long as one can create linked data for ownership, marriage, you name it it can also become a Credential. https://lists.w3.org/Archives/Public/public-credentials/2015Mar/0007.html✪
Dave Longley: Pasted in IRC comment from elf earlier. elf had modeled to confirm it would work well with Open Badges 2.0, Credentials are digitally signed and suitable for some purpose. Very generic, any domain specific areas can use their own vocabular. ✪
Dave Longley: Elf modeled it using the identity credentials spec. It modeled well, could be used in a hosted way or ...way. Can add a signature later, add a revocation date and resign. ✪
Nate Otto: Quick question, re: signed linked data. If something is revoked and needs to be resigned, should the current version be fetchable in addition to the old version. Dave: you would expect the new version to be what is retrieved. ✪
Nate Otto: We are thinking about the very best way to model achievement data into the linked data form, aligned with the credentials spec. Dave: elf has shown the importance of decentralized approach, not a rigid set of rules. ✪
Dave Longley: For example a University degree, signed and reused as a credential. General idea, keep modeled data true to it's original form but keep it general enough to mark up as a credential. ✪
Manu Sporny: Do we need to change any direction in this group? Dave: we think the model we are using can work well. ✪
Nate Otto: One action is to confirm our current approach to the Context File. Dave: we need to find a time to test on ...systems, my recommendation is to use the other URL and then switch it back once we confirmed it works. ✪
elf Pavlik: Oh, we can use rawgit.com to server context directly from github repos e.g. http://tinyurl.com/ndzsvuv✪
Nate Otto: More than a week? Dave: Yes, Manu: ASU-GSV this week. Nate: Keep me updated. Manu: we don't want to kill and important demo, but will try ASAP. ✪
Manu Sporny: Nate was your read same as Dave's. Nate: we confirmed the current approach will work well. The Badges spec for example, not all will follow the credentials spec. I think it will work just fine to have the recipient be a different email address then the organization's IRI. ✪
Dave Longley: One other thing, elf will throw together some temporary context in GIT to figure out what we want to do. ✪
Manu Sporny: Anything else we need to discuss before the next call? We will try to make progress on the experimental UC document and try to test out with Nate asap. ✪