<stonematt> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Feb/0015.html

<scribe> scribe: manu

DavidC: I'll have to leave before end of hour.

manu: Can we talk about Subject != holder or multi-subject credentials.

stonematt: Let's discuss issues first, after Agenda review
... Any new folks to the group today?

No new participants.

<cwebber> scribenick: cwebber

<manu> We have a PR here about profiles: https://github.com/w3c/vc-data-model/pull/104

manu: this PR is really ready to be merged
... we gave a heads up, 'm going to merge this thing after the call
... DavidC has rightly pointed out there's issues with the language, we'll make a PR for that
... with profiles in place, I'm going to strongly assert we can do multi-subject credentials here with the current data model, and we can do subject != holder in a variety of ways
... I think what we're waiting on is a way to mark up use cases
... we need to show people how to do a marriage certificate or birth certificate, etc... those are the use cases I've heard
... the way we support all these use cases today.. gonna take them one at a time

<stonematt> does "multiple people" = "multiple subjects" ?

manu: say you need to make a verifiable credential that makes statemnets about multiple sets of people, and the statements themselves are not connected in any way... so and so is qualified as an accountant, a plumber, etc... I don't know a compelling use case where you do them all at the same time... but for the sake of argument let's say you do. the way to do that: have the claims statement as an array
... a statement about different DIDs
... I need to look again, but I'm pretty sure you can do that today, do a verifiable credential without a group ID, can be totally separate in the same credential, data model supports it today
... we just need to show people through markup
... second use case is subject != holder
... holder can be an assistant booking a flight for someone at an organization, in that case you'd have the credential from the subject with the passport, you might have a capability on it that says the assistant can use it, and the profile is assigned using the assistant's material in some way. there's a capability in the profile or something
... that asserts that I have a profile, and if you do a bit of sleuthing on the data model, you can see that the credential I sent you didn't belong to me but I can do it. Capabilities is one way, bespoke signatures another, but data model allows you to solve it in a varitety of ways
... that's use case 2 and I'd say that the data model supports that today
... third use case: when we need to talk about multiple different subjects that have different relationship to each other: parent-child, whatever
... you're saying the subject is the holder, but the issuer also wants to make some statements of other subjects in the network. in a birth certificate subject is the person born, and in there you'd create a relationship in the frame to the parents
... so subject in this case is person born, and in their birth certificate it says the parents are X and Y. You create relationships in the frame by creating parent ???
... so that's the third use case, asserting we support that as well in the data model
... all of this is debatable , but my assertion is the data model supports it. If someone wants to give use cases, we can close off a number of these

<manu> scribe: manu

DavidC: My problem is that there is too much ambiguity in the current data model, it does allow all of these things, but it's not clear when you get a Verifiable profile, whos it is, etc.
... That places a huge amount of effort on the Verifier or protocol to find it. I'd prefer the data model to remove all ambiguities, when you get the creential, from the credential/profile whether the subject is the holder, tell if there are multiple subjects, same subject, I'd like to remove all of this ambiguity. There is nothing concrete there, far too vague.
... Who is the subject? Is it all about the same subject? You should get the credential, it should tell you what's there, it should make it easier for the verifier to prove that's the case.
... If we want to support all of these use cases, you put properties in credential/profile to indicate what it is so the issuer/verifier knows what to look for.
... I could take credentials from multiple issuers, multiple subjects, so recipient knows exactly wht they're getting

<Zakim> stonematt, you wanted to ask multiple subjects decomposable?

<dlongley> we need examples.

stonematt: Somewhat parallel comment - when we finish this, tactical discussion -- group credential use case one, multiple subjects in a VC -- question about decomposition that verifier might be able to do, don't remember how that works, but would like to come back to that. Let's finish on David's question first.

<Zakim> manu, you wanted to agree, so we need examples and correcting language.

<cwebber> scribenick: cwebber

manu: I completely agree with DavidC, I think the language in the spec is ?... we need examples. That's the blocker, I don't think talking in the issues is the right place, though DavidC has been doing great work there. We have an advanced concepts section in the spec, I think we should put these subject != holder and multisubject examples in the spec in the advanced concepts part
... marriage certificate and birth certificate seem kinda close? I'm looking for clear use cases, birth certificate is great, I'm a bit of a loss of the other two... I'm lost as to where to make totally independent claims in the same verifiable credential. I guess subject != holder is a simple one, we have 2 of 3, I just don't know what to do with the disconnected thing... I fear the completely disconnected ones may be a bad use case, but I know what

to do for 2 of 3

<scribe> scribenick: manu

JoeAndrieu: For completely independent things, we're talking about in a profile, right?

<cwebber> manu: we're talking about just verifiable credential layer, you can have two completely different and disconnect islands of information, and that could happen in verifiable profiles as well

manu: no, in a credential, you can have completely disconnected claims. you can have that in a profile as well.

JoeAndrieu: Subject broken out - optional relationship property in profile. would address good portion of David's desire for rigor.

liam: Listening to David's summary -- if you have a data model, when you're implementing, you shouldn't need any information in the data model... it should be complete.

<stonematt> JoeAndrieu: echoed David's suggestion for an optional relationship attribute on the claim to model describe nature of subject/holder relationship

liam: We have to avoid something coming in and telling us what's in the data model.
... if you can have unrelated claims/credentials come along in the same package, in same data model instance, there are security questions. You don't want someone to inject extra credentials in the process.

<Zakim> liam, you wanted to assert the dm must be complete and sufficient & to angst about multiple credentials in one thingy. although i have 3 different birth certificates

liam: digital signatures help, but they don't necessarily prevent.

<dlongley> would be good to have an example of an attack that we're concerned about

DavidC: When someone issues a credential, you can say who is creating a credential. All about the same subject, even if ID is different, or about different subjects.
... It makes it clear if it's about same person or different people
... Then we have the profile, holder who is not subject, holder has ID, ID of holder is same as ID of credential, then you know holder is subject.

<dlongley> seems like using different subject IDs for the same person in the same credential is an unwanted correlation risk more than anything.... i'm wondering what the use case is for that.

DavidC: Clearly the key must go with the ID, otherwise you won't validate the signature. Holder can put additional information in there, say whether they are all about different subjects. Holder has to say. Issuer cannot say. issuer says something is about one person, different issuer is issuing about one person. Holder then has to say - these are about different people.
... I don't think this is difficult, we just need to be more clear.
... New section on subject != holder, then examples. I need to write some examples, more ideas on how to do those. We should add this section.

<Zakim> manu, you wanted to note that rigor is up to the vocab... we have schema.org relationships and to say digital signaturs prevent injection of extra stuff

<cwebber> manu: we shoudl very carefully look at whether terms are in schema.org and reuse that

<gkellogg> +1 to keep vocabulary narrowly focused on VC and defer other relationships to appropriate vocabularies

<dlongley> +1

<cwebber> manu: we have to be very careful about introducting properties and be minimal about it

<cwebber> manu: esp if it's application or market version specific vocabulary term, because we should not be in that space

<dlongley> but ok to give examples.

<stonematt> +1 to be careful about inventing/asserting vocabulary - also +1 to have an anchor point to support something like an existing relationship vocabulary

<cwebber> manu: re what liam said: the thing at the VC/VP level... if all your credentials and profiles are signed, I reject the notion that can be tampered with easily, the signature protects everything inside the container. something outside the container can introduce injection attacks. so maybe we should talk about injection attacks within and without

<cwebber> manu: and when you can and can't trust the info

DavidC: One concern is extensibility, this is extensible, they can add properties. That's not the issue, we don't want to rule that out. We do want to have the minimum in there, minimum data model, we know what we have. People can extend it.
... About ontologies - we can specify the property, put the property in the data model, and give an example. Actual values returned by actual ontology that people should use. We can put a marker in there, have you have this field - what value is is determined outside.

<Zakim> JoeAndrieu, you wanted to talk about bringing forth semantics embedded in credential transfers in the real world

DavidC: Have to step away now, please assign items to me.

JoeAndrieu: We don't want to develop ontologies, but we do need to state relationships. Allow ontologies where we have terms for something. Vital thing here is because we're in a digital context, we don't have something embedded in real world. Giving driver's license has semantics that we lose in real world. Profile saying holder, that's important. optional relationship field we can address w/o too much complication/overhead.

<Zakim> liam, you wanted to note a malicious credential gets signed

liam: Digital signatures reduce chance that something can be tampered with, but they don't stop someone malicious from adding things before something has been signed.

<dlongley> hmm, they aren't signed by your "trusted store" they are signed by the issuer -- so the issuer (or someone attacking the issuer in some way) would have to inject something malicious.

gkellogg: Going back to keeping vocabularies narrowly focused, there is an interop consideration. We should keep VC vocabulary focused on claims themselves, but if there is no best practice, specific classes properties from schema.org, then we have a tower of babel problem understanding what's being said.
... Maybe we could use SHEX or SHACL that is a constraint language, create a profile that people can test against wrt. interop.

We have an issue for this: https://github.com/w3c/vc-data-model/issues/76

<Zakim> tzviya, you wanted to ask about subject !=people

tzviya: Almost all of the use cases have subject as people... Manu had mentioned schema.org, some use cases could be creative works that are the subject. Publication/book is the subject.
... School issuing may be subject, book may be subject, school may be receiving credential. People are not always the subject. For topic of bundling, could be people AND orgs.
... Institutional credentials that have a collection of people. Institutional access, collection of people. We have to think broader than people.

<Zakim> manu, you wanted to respond, we support that.

<Zakim> stonematt, you wanted to discuss the groups of people idea

<cwebber> manu: it's important to do examples around things that aren't just people, you can even do examples around concepts such as love or the sky, but we need to provide more concrete examples around that

stonematt: Without getting into the weeds just yet, Joe and I met about use cases discussion. Talked about organizations that have individuals that are granted access to libraries.
... I'd like to wind this discussion down, spin Joe's use cases discussions back up.
... Anyone else want to provide input here?
... great discussion, btw... this was a healthy and productive discussion.

<JoeAndrieu> +1 for pulling in the PR

<cwebber> manu: if you look at the ?? spec you can see lots of examples, we could take the same approach here, or we can link off-site to the use cases. if every use case has an example of the kinds of credentials made in the process that can show that we're done

<cwebber> manu: so maybe this is a good segway into the use cases: once we've identified use cases, how do we identify when they're done. where do the examples reside? I think we'll need a conceptual example in the spec, but can put specific examples in use cases doc

<scribe> ACTION: Manu to create 3 new advanced concepts sections - subject != holder, multisubject, data islands

Use Cases

JoeAndrieu: How do we know when we're done, and how do we represent it?
... This is an eternal question in requirements engineering.
... We're done when we're done, but that's tautological.
... As for where we put it in the document, maybe we need 5-6 focal use cases. 5 is the ideal number. If we are going to do a straightforward interaction, and sticky wicket, those are two different use cases.
... There are easy versions and sticky wicket versions. Don't know trade-offs on where to put it in the document.
... Focal use cases, illustrate how we meet them.
... We have walked through Tzviya's use case, understand what it meant. We have a couple of different architectures, whitelist directory... whitelist is not that interesting. That's straightforward w/ data model already. Trust framework seems more interesting. Issuer issuing claim under trust framework.
... There is a system allowing certain members at one University to access another University.

tzviya: Open Athens

JoeAndrieu: So, access for student to shared resources. I don't think we have in the current data model, for issuer to provide information stating their authority.

manu: We do have evidence?

JoeAndrieu: feels like a square peg, but we should think about it in a bit more depth.

<dlongley> the issuer itself can have its own credentials, which could be discovered by dereferencing its identifier

JoeAndrieu: Matt's use case - someone has enhanced diploma, grades on classes, in 2a, labor market (monster.com), the subject of that wants to selectively disclose grades they got in classes. They don't want overall GPA.
... That may be the simple version, we don't know where the sticky wicket is.

<dlongley> ^i would expect that to be the main way to keep discovering more information, if that's needed... just keep dereferencing subjects to discover more information/credentials.

JoeAndrieu: That's ongoing work.

stonematt: The nature of relationships between issuers to issue related credentials. Category of discussions that we haven't uncovered much.
... Tzviya's assertion about university case, IP rights to grant credential, delegate credential to someone in my network to do training on my behalf and grant my credential. Issuer delegation.

tzviya: Tzviya's use case, we could jointly issue PAC10 credentials that are equal to one another, each one would get university access anywhere in the world. Harvard may view all those credentials as equal.

JoeAndrieu: Maybe we can try evidence first, see how that works out.

stonematt: Maybe what we're talking about here is "jurisdiction", do I have authority to issue this type of credential.

<tzviya> the existing Ed use cases https://www.w3.org/TR/verifiable-claims-use-cases/#education could be fleshed out further

JoeAndrieu: My update - use cases haven't been updated in a while, want to focus it around use cases we looked at. Since we're exploring deeply.
... Maybe we can pick 3 use cases, 2 variations (easy / sticky wicket)

dlongley: Respond to use case that we're talking about - authority that's issuing a credential to a number of universities, universities issue their own credentials.
... In process of verifying student's credential, if you don't trust issuer, you can dereference issuer to discover credentials about the issuer. You could then discover that the issuer has a credential from an authority that you trust. you can dereference identifiers to find more information. Also works well wrt. CG, putting public credentials on blockchains, or find services to find credentials. I expect use case can be discovered via identifiers, whether

or not you should trust credential at bottom of tree.

<Zakim> manu, you wanted to note that some of these are object capabilities use cases, not verifiable credential use cases.

<cwebber> manu: delegation was mentioned a couple of times... I agree with what dlongley said in that we have a very cool and flexible discoverability mechanism. Typically people do it through very rigid trust frameworks today. the data model we have enables far more dynamic trust models, and you don't even need federation for some value of "federation"

<cwebber> manu: but there's this concept in linked data called "follow your nose", if you're not sure of the info you got you follow your nose to those links so you can get a more educated information to what you do. equivalent to picking up the phone and calling a reference to see if someone's a good employee at previous job, etc. I think that's a powerful idea

<cwebber> manu: also I wanted to point out we're talking about delegation, because we could easily throw verifiable credentials at that problem but we're also working on object capabilities but that may be a better fit to do this

JoeAndrieu: I do think object capabilities may be a good way to deal w/ authority.
... We could do it w/ dereferencing, authority may not be publicly listed, issuer publishes everything, or verifier needs to check all their trusted sources. For small use cases, not difficult, but if explit mention is in data model, it makes verifier's job easier.

stonematt: We're at time, top of the hour, time to adjourn.

<dlongley> it's hard to list the authority explicitly -- you still have to dereference it

<JoeAndrieu> cheers

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/is/does/
Succeeded: s/my my/, but my/
Succeeded: s/Open Access/Open Athens/
Present: Benjamin_Young Dan_Burnett Dave_Longley David_Chadwick Gregg_Kellogg Joe_Andrieu Liam_Quin Manu_Sporny Matt_Stone Richard_Varn Ted_Thibodeau Tzviya_Siegman
Found Scribe: manu
Inferring ScribeNick: manu
Found ScribeNick: cwebber
Found Scribe: manu
Inferring ScribeNick: manu
Found ScribeNick: cwebber
Found ScribeNick: manu
ScribeNicks: manu, cwebber
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Feb/0015.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: manu

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)