<burn> scribenick: agropper
<stonematt> Yancy Ribbens
Yancy: software dev interested in did and use case allowing mre freedom in online id and wantts to contribute in tech fashion
chris spanton: fron Tmobile involved in a number of identity Hyperledger - Next Idendityu project under hyperledger
<stonematt> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jun/0003.html
stonematt: Agenda: action item
review then pull request then use case document and if we have
time discussion around Type in the spec - how is it evolving?
is it closing?
... good discussion but targeting closure as we go on
<stonematt> https://docs.google.com/spreadsheets/d/1XIRn3VltrK_Dxqz0VyDxPi265sW47EMSKVKUXmMkI70/edit#gid=0
stonematt: AI review one item to @manu - he's not on today - #39 is being closed
<stonematt> https://github.com/w3c/vc-data-model/pulls
stonematt: PR review is the next
topic - all about URL -
... #170 clarified terms of use
DavidC: looking - we resolved (with DaveL) we don't need to mandate the terms of use type at the moment - unless there's a target
<dlongley> scribe: dlongley
DavidC: I'll try and update this PR in two ways before the next meeting. Bring it inline with all the new changes (rebase it). Remove the TermsOfUse type from the terms of use object.
<burn> dlongley: don't think anything else is needed here.
https://github.com/w3c/vc-data-model/pull/170#discussion_r191437063
burn: Let me take a look at your
edits and see if that addresses it.
... I will look at it offline.
I'll take a look too offline and provide a review.
stonematt: Quick process question -- is it right for David Chadwick to make the edits and remove the merge conflicts?
<TallTed> rebase is not necessary!
<cwebber2> dlongley: what you want to do is a rebase, and then a force push
<cwebber2> DavidC: I haven't tried rebase but I can try
<cwebber2> dlongley: I think github has an automatic pull and rebase/squash feature
<cwebber2> DavidC: I'll probably email dave or manu if I get stuck in the week
burn: I remembered my comment but I don't see that you've made any changes to the "MUST" I was commenting on.
DavidC: Yes, that is correct. I hadn't made the changes because I thought you were arguing it shouldn't be a MUST but I think it should be.
burn: No, my comment is about the structure of the sentence. The way it's phrased, it is not testable.
DavidC: So you want it to be rephrased.
burn: Yes, that's correct. If you
re-read right above that comment. The second MUST isn't really
testable. "The value of this property MUST be one or more terms
of use ..."
... "how they MUST utilize the given information" <-- that
"MUST" is not testable.
... I think what you'll find is that probably that MUST needs
to change to "are to" -- it's not a normative statement about
how utilization needs to happen. You may need other statements
that then explain what the MUST part is. In that sentence, that
MUST is not testable.
DavidC: Right. The thing is we're talking about that we don't know what it is because it hasn't been defined. So when we have to say the verifier must do X then that will be defined when the terms of use are defined.
stonematt: One of the challenges I think we have with this kind of discussion is that the charter of this effort is data model. And "hows" are really more implicitly referring to an implementation or a protocol. I think we're in a gray zone. I think we should be careful about what we're setting up as a testable case for the data model itself. We should refer to a future functionality about how we expect the data to be used that is not so normative.
burn: The way that second MUST is phrased here is not testable, please reword that sentence and change "how they MUST utilize" to the "verifier MUST" -- and if you can't put something after that MUST then you must take it out. It's not a testable statement for the spec.
DavidC: I have thought of something, yeah, ok. I will give you some text and see what you think about it.
burn: Thank you.
<stonematt> https://github.com/w3c/vc-data-model/pull/169
stonematt: This is a new section
related to subject != holder.
... Are we tracking towards closure on this as well?
... Do you understand what Manu is asking for and are you
working it out with him? He's not here to represent.
DavidC: One of the bones of
contention here is how relationships are specified between the
person who is the subject of the credential and either the
holder or someone else. I put in a relationship object that
said that the subject is related with the following
relationship, etc.
... What we had in that relationship was a fixed parameter was
"relationship" the property and the "type" would change.
... Dave Longley wanted the property to be the relationship. In
my model the property was "relationship" and the relationship
was the "type". In Dave Longley's model the property was the
relationship.
... It's a modeling issue. There are arguments for and against
both basically.
stonematt: Is this something we
should solve in this PR or should we track it separately?
... Would there be value in getting this pulled in now as it
stands?
DavidC: Because the topic is subject != holder, then there has to be some sort of relationship between them. Where we have the case where the subject == holder, probably the most common case, then there is no requirement for the relationship. In a way it's fundamental to the question -- "Who is this holder?"
https://github.com/w3c/vc-data-model/pull/169#issuecomment-394127351
<cwebber2> dlongley: I don't want to deviate with the path we've been taking, I want to come up with a solution that takes into consideration eg what Joe said before
<cwebber2> dlongley: DavidC is arguing add the relationship then add it through a type property, but that does two things, it limits what you can say in a graph. Existing model allows you to create all sorts of relationship properties, it's open world, not limited to a single field, allows describing complicated realtionships between eg holder and subject, rather than say there are just 3 or 4 ways that you're related... we show a mechanism for describing
<cwebber2> relationships, and we let implementations fit in what the relationships are. this follows the existing standard work we're doing, open world assumption, pin down relationship between holder and subject, where should we do that... should we reuse what we're doing? should we do a third thing? it seems like in this PR it's a third thing, I'd like to reuse what we have and the standards we're piggybacking off of
<cwebber2> dlongley: I think we need a counterproposal, I can take an action item to work on that
<cwebber2> dlongley: yes, I think we can keep working in this issue, maybe get feedback in this issue from joe and manu, we can work it out in the issue tracker, we're just not ready to pull it in yet
<cwebber2> DavidC: yes and I'd say historically dlongley and I end up agreeing
stonematt: Tzviya can you give an update on where we are?
<stonematt> current use cases: https://w3c.github.io/vc-use-cases/
tzviya: I haven't had a chance to catch up on minutes from last week, has this group been caught up on the traveler focal use case?
burn: We didn't discuss this at all last week.
<tzviya> https://w3c.github.io/vc-use-cases/#international-travel-with-minor-and-upgrade
tzviya: So we have three focal
use cases in the use case document. We've gone through the
citizenship -- and we need to talk about a parent traveling
with a minor.
... We combined subject != holder in here because you have a
parent traveling with a minor and upgrading a seat to first
class (commerce)
... I don't imagine you've all read through it in the moment,
there's a lot of questions here because, for example, we're
from the US and we don't know if passports work the same in
other countries. The basic model is one parent traveling
without the other parent. This needs notarized documentation.
We have that provision in the claim.
... We have the two passports and subject != holder. We have
the parent upgrading to first class.
... The main question I have for the group -- US passports, the
child passport has no information about the guardian. My
husband and I had to travel with extra documentation, it's not
on the passport. We have "guardianship" as implicit. Does
anyone have information as to how guardianship is established
in other countries?
... Or should we leave this as implicit?
<stonematt> https://github.com/w3c/vc-use-cases/issues/71
stonematt: We might have some
more discussion about it on github.
... I think there are a couple of different places where we
might indicate the relationship between the minor and the
parent. It could exist in the minor passport. The department of
state in the US doesn't maintain that and if there was a change
it wouldn't be reflected in the passport. There's probably some
other document that represents current guardianship.
... It could be in doc where parent A is giving permission to
parent B -- note guardianship there.
DavidC: In the case you're
referring to -- if the child is not there the passport is not
much use. It's not the same as "subject != holder" because the
child *is* present.
... What you're also wanting is a different credential where
it's saying "I'm the parent of...". When we were thinking
"subject != holder" the holder wasn't even present.
stonematt: I think when you're presenting to the gate agent everyone is there, that's true, but when buying online the child may not be present. The minor never gets to be the holder until they are not a minor.
DavidC: I buy tickets for my wife online and I just say what the credential is. And they validate it when you show up at the airport.
TallTed: This seems to me to be
going significantly into the weeds about who maintains the
guardianship or authority to travel with the child. Someone is
presenting a claim that needs to be verified. The degree to
which we nitpick every layer of that, yes these are use cases,
we need at some point to genericize. "Subject != holder", well
yes, the subject is the child and the holder is the parent,
whether the child is present or not is immaterial.
... Then going off on whether the parent has the authority to
travel with the child -- they are not necessary to me, spending
significant time and energy on it and we'll need to do it for
every nation in the world.
stonematt: I think what we wanted to do in these focal use cases was have a use case that resonated with a large enough population where it makes sense and showing that the data model works.
TallTed: If I'm traveling with the child of my divorced wife and I and we're going from Britain to France then we can talk about it. If we get more complicated than that we're digging ourselves a huge hole.
stonematt: So we can focus on the US and stick with that because we have contextual expertise.
TallTed: Yes, but the US may be a bad example because there are different states. I live in Boston, my ex-wife lives in California, I want to travel with my child to Britain. But even that still goes into the weeds.
<liam> [ it gets even harder when a marriage isn't recognized everywhere, e.g. same-sex marriage or trans people ]
stonematt: I think maybe we can step back a little bit and talk about the value of the use case. Let's try and confirm that our goal was several different stakeholders, parents and minor, coming together with a presentation that they can give to the verifier (e.g. airline) that they've done the things required for these two to travel together. This sort of opens us up to a discussion about who is holding the credential and has the rights to grant a
permission, etc.
stonematt: This seems very relevant in the last two weeks. I saw a woman in the news -- she was questioned about traveling with a child that was biracial and has a different name, etc.
TallTed: I fear the use case that
is being delved into is sufficiently fraught with peril that
what we're trying to dive into (who is presenting and the
credential gives authority) but the depth the use case is being
dug into will delay the utility of it. This particular use case
has so many tie ups. There are also marriages that are not
recognized everywhere, how do you deal with that?
... None of that is relevant to this group's work, only
relevant to the *use* of this group's work. We don't have to
tell the airline how to check with the state department or the
families, etc.
+1 to TallTed -- let's keep it simple without having to bring in too much
tzviya: This is based on a real
world example. I think it's a good suggestion not to solve it
for the whole world. I think we should make this the mother is
traveling from X to Y and just decide on that.
... We're intentionally choosing sticky cases so we illustrate
this is a viable model.
TallTed: It's the level of stickiness that I'm questioning.
stonematt: Maybe more clearly assert that the parents have guardianship and have proved it in their jurisdiction and that would address Ted's concern. And we're just trying to assemble the documentation into a presentation the airline can verify.
<TallTed> +1 for making some background assertions to cover the stickiness that is not about what we're doing, but is about the legal twists and turns...
stonematt: And if we're reasonable and say this works at this jurisdiction then presumably it could work elsewhere. It would hopefully then work for the community to show how it could be reapplied in those other cases.
+1
stonematt: Thanks very much for
that discussion, it helps the use case people as we draw
boundaries around our scope.
... They are by definition tricky.
... Any other comment on this use case discussion? I don't
think we have enough time for the next item. Any other
business?
stonematt: Question to the team
is -- whether we should have a meeting on the 3rd or skip a
week?
... Dan any other background?
burn: No, I would just ask if anyone objects to canceling the meeting?
no objection from me, wouldn't be there anyway :)
No objections
<stonematt> i just lost my voice connection. Thanks to all. burn will you close us down
burn: Meeting is over! Thanks to our scribes and talk to you next week.
<burn> we are closed
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/stanton/spanton/ Succeeded: s/burn: Agenda/stonematt: Agenda/ Succeeded: s/burn: AI/stonematt: AI/ Succeeded: s/burn: PR/stonematt: PR/ Succeeded: s/burn: #170/stonematt: #170/ Succeeded: s/event/even/ Succeeded: s/etc. so on./etc./ Succeeded: s/towards closer/towards closure/ Present: Tzviya_Siegman Dave_Longley Matt_Stone Dan_Burnett Christopher_Spanton David_Chadwick Liam_Quin Nathan_George Ted_Thibodeau Chris_Webber Adrian_Gropper Yancy_Ribbens Allen_Brown David_Lehn Regrets: Manu_Sporny Found ScribeNick: agropper Found Scribe: dlongley Inferring ScribeNick: dlongley ScribeNicks: agropper, dlongley Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jun/0003.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: 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.)[End of scribe.perl diagnostic output]