Agenda review, Introductions, Re-introductions

<dlongley> scribe: manu

burn: Two main topics for today - subject != holder and type

DavidC: Terms of Use has been updated

burn: Can we delay that one?

<dlongley> manu: There's another one that Bohdan's been talking about. There may be 3 issues we could possibly close, has to do with extensibility. Maybe 5 minutes to propose and see if we can move forward with that.

burn: Let's keep it very short
... Any other additions to the Agenda?

No additions

burke: Hi Bob Burke, at Koupon Media - CTO here, watching Verifiable Credentials work, looking for opportunity to support it.

ganesh: Hi, Ganesh at Digital Bazaar - doing software dev at Digital Bazaar, doing work on Verifiable Credentials.

Yancey: Hi Yancey, from Credly, fairly new to the group.

Action Item Review

<burn> https://goo.gl/V4XTBT

burn: We had one open issue... Dave Longley - code sample for Traveller use case.

<dlongley> https://github.com/w3c/vc-data-model/issues/187

burn: Ok, thank you - closing that action item.

Assign owners to unassigned issues

<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee

Attachments and References for Verifiable Credentials

<dlongley> manu: The summary here is that Bohdan wants a way to attach a piece of paper or other credentials to another VC -- or to attach an image of a driver's license associated with a driver's license credential, supporting documentation, etc. These are all legitimate use cases.

<dlongley> manu: The contention is whether or not it should be in the core data model spec. Dave Longley and I have pushed back and said that we think more work needs to be put into the data modeling for the specific use case -- we don't agree with the way the use case is being solved but that's neither here nor there -- it's in extension territory.

<dlongley> manu: His response to that was essentially that he didn't know how to do that, so the response is to write a section on how to create your own extension to the data model.

<dlongley> manu: We already have a section on extensibility and we say how to include a context/vocabulary to extend it but we don't talk about why or give guidance.

<dlongley> manu: If we added this then hopefully Bohdan could look at that and say "Oh, I attach these two files and add this vocabulary that's how I do what I need to do." What do people think of this idea? Do people like this approach or do people want to add something to the core model?

burn: I agree on the next step - create a new paragraph or five for the spec. Doesn't sound like we need something else.
... But we need to explain that.

DavidC: Attaching is not new, it's been done w/ X.509 - you can already attach into signed constructs... it isn't difficult to show demos based on state of the art examples.
... However you add a proven evidence as an attachment should be how you provide a photograph... don't think you'll have an extra mechanism, we can just use evidence.

nage: The more we can outline what the principles are, and the less prescriptive we can be, the more successful we'll be. If we can outline the requirements, mutability/immutability of the reference - fits in the schema, part of data issued to subject, or just supporting evidence... I don't expect that's a part of Terms of Use... more about claims. The more we can talk about those principles, the more people will get claims right and will interpret claims

correctly.

<dlongley> i agree with Nathan -- semantics around why the "attachment" is there are important and that was my argument against being super generic

<scribe> ACTION: Manu to write PR for Attachment use case.

<DavidC> I am arguing that the way you reference an attachment should be generic, e.g. hash and url, but where it is located in the VC, i.e. the semantics, are very important and will be different

agropper: For health record, a photograph may be taken, just local biometric to the system... asking whether this particular issue would allow an online equivalent of that? If I as the holder of a Verifiable Credential choose to attach my photograph to it, that that photograph becomes available when I use that credential?

<Zakim> manu, you wanted to respond.

<dlongley> DavidC: I think we'd be in agreement there

<dlongley> manu: The way that they would probably end up doing that, the holder, at the time they are handing over the original credential, like heart rate at a point in time, or a prescription, etc. -- they'd add their own credential with a photo I took of myself or whatever. They'd just create another VC and send it along. There are multiple different ways to support that use case. I don't think we're saying one way or the other is more correct.

<dlongley> agropper: Thank you.

burn: Anything else on this topic? We have a next step... Manu will write spec text.

Subject != Holder update (PR 169)

<burn> https://github.com/w3c/vc-data-model/pull/169

burn: This one is waiting on an example from Longley... want to talk to that?

dlongley: Wondering if this is the same thing -- would this be resolved by having example for traveling use case?

burn: Yes, I believe so - traveler use case is necessary... Matt was suggesting you do both of the use cases. Traveler use case would be sufficient.

DavidC: Yes, I took a look at that example, didn't see the type... seemed to be missing.
... This is tied into the type discussion?
... There is no other type in the presentation... that worries me... maybe we should have the type discussion first. I thought the type controlled the contents of things... if you don't have a type, you don't know what you have.

<burn> https://github.com/w3c/vc-data-model/pull/169#issuecomment-396641325

<dlongley> https://github.com/w3c/vc-data-model/issues/187

dlongley: That is in response for Travel use case... that has a lot of type information in there... I did not do a Verifiable Presentation, which would include these issues.
... There are a number of type fields in here.

DavidC: I proposed a relationship object, which is not necessary, but you were going to draw up JSON constructs for credentials and presentations, but conveyed the same information that included relationship objects.

dlongley: look at issue 187 - we have 4 examples that provide relationships w/o generic relationship property.

DavidC: Ok, can't process this on the call right now... will review offline. If this does do what we want to do for Subject != Holder, then that would be fine. Let me have a look and digest.

Issues related to Type

<burn> https://github.com/w3c/vc-data-model/labels/Type-Discussion

<Zakim> manu, you wanted to introduce the issue

<dlongley> manu: Fundamentally, the "type" property is a JSON-LD thing. Speaking generically w/JSON-LD not VC specifically. "Types" are not necessary in JSON-LD, there are many objects where you don't know the type. The way RDF inferencing, etc works is that you can divine a type based on the properties used in an object. For example, if an object has a "motor" property, v6 6 cylinder engine, etc you probably know it's a machine of some type. You don't know for sure

<dlongley> if that's true, it could be a motor in an artificial heart but it's some kind of machine aspect.

<dlongley> manu: Typing in JSON-LD is a set of things you can infer. You do need inference engines built on top of that stuff so we tend to stay away from that. I just want to ground the discussion to say you don't *need* types. A lot of code isn't keyed off of type. That's to say it's not absolutely required that you have a "type" you can key off of properties -- neither approach is viewed as "correct".

<dlongley> manu: Now let's layer VC on top of that.

<dlongley> manu: At least in this spec, there are certain things you can count on. If a type of "VerifiableCredential" is used then you know there are certain properties that you can check for. I think we've made a decision in the group that some types are required.

<dlongley> manu: If you have a "VerifiableCredential" then you have to include that type. Then a question was raised by David regarding "what about Term of use", etc.

<dlongley> manu: So for some things in the spec we say there needs to be a type and other times we don't. The reason that is today, is because we don't know what those types will be in the future. For evidence and terms of use we don't necessarily know what objects will go in that place. There's a home/bucket to put them in, but we haven't done the data modeling to be very specific about that.

<dlongley> manu: For example, the ODRL could be used for terms of use. That's just one option for expressing terms of use. There might be others.

<dlongley> manu: The discussion has gotten to the point where "type" is important in certain places -- such as when you know there will be certain properties there. And other places, there are no such properties. There's nothing that will always exist in "evidence" or "termsOfUse".

<dlongley> manu: I think that's where the discussion is today. I think -- David Chadwick will have to correct me -- there's a realization that "type" in and of itself, if it doesn't signal anything else, if it doesn't signal anything, it isn't required.

<dlongley> manu: If we can't figure out what kind of code path we'd trigger using a type then there's no type requirement.

<dlongley> manu: That's just a background on where we are on various discussions.

<dlongley> DavidC: I think we do have a fundamental disagreement. The model as described by Manu is too squishy. The model I'd like us to have is that when you parse a VerifiableCredential you know exactly what you're getting from the type and whether you'll accept it or not.

<dlongley> DavidC: The "type" should control all the other properties that are prevalent with that type. Consider it like LDAP. Where it indicates everything that will be present in a directory.

<dlongley> DavidC: If we're going to say that type doesn't indicate anything it isn't necessary, ok. But then there's no "TermsOfUse" but other types where there are common properties are required.

<Zakim> manu, you wanted to agree, I think?

<dlongley> manu: I'm wondering where the disagreement is?

<TallTed> Implicit typing mandates inference/reasoning in tools that consume the data. Explicit typing lowers the bar for verifying, etc. I believe there are other reasons to encourage explicit typing; the only reason I know of to discourage explicit typing is the "extra" triple.

<dlongley> DavidC: You implied that there would be certain squishy objects where there's no type and you don't know what you're going to get. And you have to infer what you get from what you find there.

<dlongley> manu: Here's where I think we agree -- which is pretty much everywhere. If you have a "type" it is signaling something. There is some set of properties to expect.

<dlongley> manu: We could prevent objects having no type information having no type information whatsoever. We could restrict the RDF/JSON-LD model in that way.

<dlongley> DavidC: That's what I would like to see.

<dlongley> manu: Ok, that's the only point of contention here.

<dlongley> manu: We agree that if you have a type then it signals other properties. More than likely in almost everything will have a type if it's well specified.

<dlongley> DavidC: I'd like to just say that if a verifier gets a credential and the properties do not match then the verifier must reject the credential because they don't know what they have.

<dlongley> DavidC: This credential is giving privilege access to something, a job, passport to travel, whatever. If you have these properties that don't match the type then you don't know what the credential is saying.

TallTed: In a similar vein, I think what you're saying David... that type is giving a hint, there are other things to look for, other things to check. Explicit typing lowers the bar that's necessary to evaluate anything.
... You have to check what values are, inference and reasoning may not be necessary if the type is explicit. There are a lot of arguments for explicit typing. The only argument I'm aware of against explicit typing is the the extra triple. Some query engines have performance issues if type is included.
... Here, you're looking at a piece of data... feels simple and straight forward.

DavidC: The specification says the type must be a URL... that is covered by @context... keyword is URL... we had said that understanding JSON-LD is not mandatory, doesn't this make it mandatory to understand JSON-LD?

dlongley: Using the short form where you do not use a URL in the type fields... I hesitate to say "understanding JSON-LD"... in the sense that you are using understanding JSON-LD, I think that's true... I don't think regular developers need to understand this.
... You can do string checking, developer writing verifier software, you don't have to understand JSON-LD. If you are going to use regular strings... use JSON-LD syntax, as a developer, you don't have to understand much at all.

<TallTed> (are we mandating JSON-LD for verifiable credentials? suddenly it seems so ... and that's very very bad imho)

dlongley: An analogy - people that put schema.org information on their websites ... many of them know little if nothing about JSON-LD, but are able to use the format.

<TallTed> (mandating JSON would be similarly bad)

DavidC: Some people put common names, look up tables, object identifiers... CN strings... it's a bit of a mess.

<TallTed> these should all be URIs. literal strings BAD BAD BAD in RDF universe

<dlongley> manu: Standards are about compromise. I'm fine at this point just ratcheting the standard down -- every object in a VC should have a type associated with it and if it's not there the verifier can throw an exception. I find Ted and David's arguments compelling, I'm just worried about being overly restrictive. I don't have a strong case for not including a type in there otherwise.

<dlongley> manu: What if the spec said that "type information is required for any object associated with properties in the specification".

<dlongley> manu: I'd need to check that. We don't want to limit that further down the change. The JSON GEO folks are using JSON-LD and they aren't including type information and it would be onerous to make them do it. That's an example of the GIS community with a real use case where there's no type information.

<dlongley> manu: Dave Longley also raised a point about "claim" ... I need to do a pass on the spec for this. Some people might not want to say an entity is a "Person". So some properties might require types but others not? Maybe that's the approach we could take? I don't think we can do it for everything.

<dlongley> manu: "claim" is an example where I don't believe we should mandate "type" in there.

<dlongley> manu: For "evidence" and "termsOfUse" that makes sense. Maybe we say "for these properties x, y, z" that we require type there.

<dlongley> DavidC: I do disagree with you. It's not difficult to say what type of VerifiableCredential a VC is.

<dlongley> manu: I agree with that that a VC should have a type. There's a miscommunication. The "claim" should not need it.

<dlongley> DavidC: No. There's another issue that "claim" should be "subject" ... that's just a property not an object.

<dlongley> manu: This is actually a good example. In an over 21 VC, there will be claim, one, that will be "id" that establishes the subject identifier and then also the property "ageOver" with 21. There's no "type" in there.

<dlongley> manu: No "Person" or whatever it is. Do we mandate type there?

<dlongley> DavidC: No, we don't need "type" this entity could be a block of wood. We don't have to say a "type" there.

<dlongley> DavidC: We're not saying that, it's just an age.

<dlongley> TallTed: That's essentially what I was going to say. When you look at a passport, it says all over it that it is a passport. It says your citizenship and that you are you. The argument against saying these things seems spurious to me.

<dlongley> TallTed: There are communities that don't want to include type information. And that won't be problematic in their small sphere but as the data moves it becomes less obvious and the consumer has to do more heavy lifting to figure out types.

<dlongley> TallTed: Lots of data has properties and because this is open world -- if the subset that is actually there that you use to identify a class isn't there then you're out of luck.

<dlongley> manu: David just made the argument I started out making and Ted you're being consistent with the original argument.

<dlongley> manu: David, I keep seeing you switch your position with where "type" is in the hierarchy. I said I could agree to having "type" always exist and Ted agrees. But when we're talking about "claim" we're talking about the information associated with the claim, not the VC. In that object that's associated with the "claim" do we need to require "type" there or not? David says "no" and Ted says "yes".

<dlongley> manu: What we can't do at this point is that we can't say that every object in a VC has to have an associated type.

<dlongley> manu: I think David is agreeing and Ted is disagreeing.

<dlongley> DavidC: My basic point is that we should know when we process a VC what will be there and what won't be there. Whether it's on the object itself or the level above you can actually know from the type itself.

<dlongley> DavidC: VC specifies the high level properties are ... and the subtype tells us what else will be there. I think the "Person" argument is a red herring. We could put that "type" in the claim .. . I don't feel strongly about where it is but it needs to be there.

<Zakim> bigbluehat, you wanted to ask about age gates

<dlongley> bigbluehat: I want to leave "type" out of claim.

<dlongley> manu: I can do a PR that can call out the properties where a verifier MUST throw an exception when it doesn't see type information.

<dlongley> manu: That will allow us to make progress and fine tune where we agree/disagree.

<nage> The mix of things inside vs outside of claims continues to be an issue. Manu, do you see the "must throw an exception" the criteria for that?

<burn> ACTION: manu to do a PR that can call out the properties where a verifier MUST throw an exception when it doesn't see type information.

<dlongley> manu: I want to underline what Dave Longley is saying is that there's a fundamental misunderstanding of the graph data model.

<dlongley> where "type" is changes which subject it relates to.

<dlongley> manu: I'll do a PR.

<scribe> ACTION: Manu to write PR for @type requirements.

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)

Present: Dan_Burnett Allen_Brown Liam_Quin Adrian_Gropper Dave_Longley David_Chadwick Manu_Sporny Ted_Thibodeau Nathan_George Ganesh_Annan Yancey Bob_Burke Benjamin_Young David_Lehn
Found Scribe: manu
Inferring ScribeNick: manu
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jun/0010.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.)