<DavidC> I am currently on holiday in Greece, so due to the time difference I can only stay for 30 mins
<stonematt> AdamL, AdamM, DavidL, NathanG, MattL, BenjaminY, KimHD,
<stonematt> TzviyaS, TallTed, MattS, GreggK, DavidC, DanB, Manu, Longley, ChrisW, JoeA,
<scribe> scribe: nage
<stonematt> scribenick: nage
stonematt: subject != holder
status today as well as time reserved for next focal use
case
... lets address subject != holder first
... call for introductions now
Markus Sabadello introduction
markus: I have been working on credentials for quite some time, I was just nominated as a W3C member by a local university so I plan on joining this discussion going forward
stonematt: we will now jump
straight to the milestone update of subject != holder
... we had started this effort a couple of months ago and we
have some PRs in the works
... we haven't spent a lot of time on it in our calls for a
while
... what work is left to declare victory on this topic?
DavidC: I raised the PR. It seems like there is too much in there to be accepted at the moment without some sort of minor edit
manu: The only things that the
discussion is focused on are the examples. I thought the text
is largely fine
... it identifies the times where subject != holder
... most of the concerns seem to be around the examples
<Zakim> manu, you wanted to provide some input on S!=H
manu: if we mark them TBD in the data model later, that might point out that the core concepts are solid there.
<dlongley> +1
DavidC: I'm certainly willing to
do that if it is acceptable and pushes us forward
... before next meeting I can probably update the PR along
those lines
manu: if we put TBD on all the examples and have one more edit pass on a few paragraphs, then we could try to get it in
DavidC: fine, thank you
stonematt: is that an action to
pull in PR 69
... and then do some clean up afterwards?
manu: lets have DavidC update it in his branch, then let the PR people handle that next part
<stonematt> ACTION: David to update examples in his branch and work to pull in PR169
DavidC: I can do that
manu: That will really move us forward
stonematt: I don't expect that will clear the milestone right away, but it will move us closer in this discussion
DavidC: there is a problem with
the diagram conversion to SVG, so I'll need some help with
that
... how should we resolve the diagram issue?
manu: If it is isn't complex, you can create the diagram in Google Draw and it will direct export to SVG
liam: saving as PDF might work too, because you may be able to open it up in an SVG tool
<stonematt> ACTION: DavidC to attempt rendering the diagram in GoogleDraw and save as SVG, if not ask for help.
<cwebber2> that's probably going to be a very messy svg
liam: Inkscape can usually do it
DavidC: If I email the pdf to the list, would someone have a go at it?
manu: those conversion steps usually make messy SVGs, so recreating in Google may be better
stonematt: if you can't make progress, email the diagram to the list and the community will help
DavidC: I will do that as a fall back position
stonematt: any more discussion
about subject != holder?
... lets review action items
<stonematt> https://goo.gl/V4XTBT
stonematt: the link for action
items is in IRC
... DavidC I am closing the action item for existing PRs
because I believe it is finished
... I will follow up with burn on his task
... cwebber2 and nage have a task to connect up on the test
suite
nage: I sent an email to cwebber2 and we have a few folks getting involved from the Sovrin side that may be able to help things move forward more quickly
<cwebber2> nage, I just saw your email come in
<cwebber2> I'll read and respond
stonematt: we will follow up on this again next week and try to track it as issues in the test suite repo
+1
stonematt: looking at unassigned
issues in the vc-data-model repo, there are two old deferred
issues, so we appear to be clean
... now moving to focal use cases
<Zakim> manu, you wanted to provide update pn PRs.
manu: before we move on, I
submitted a number of PRs around MUST and SHOULD and resolving
profiles to presentations
... and adding things to the security section on token
binding
... there are new PRs there that would be good to go look
at
stonematt: it looks like there is
some activity there already, that is good
... do you plan on pulling these in this week?
manu: yes, we discussed them at the F2F, so we hope to pull them in soon as non-controversial, but we usually give 7 days for folks to respond.
stonematt: any more on PRs from
the group?
... anyone that is interested, go through the pending PRs and
give feedback as necessary so we can move these forward
... next topic is focal use case review with JoeAndrieu
... there is a third use case that relates to commerce in
guardianship that we'd like to discuss
<stonematt> https://docs.google.com/document/d/1O-PYcHZYvbjbhONRSdSwdCP2cwg77bxadAJQdHdI66A/edit
stonematt: as we prepare to bring these into the actual respec doc
JoeAndrieu: the focal use case we
are discussing today is 3.6 "parental ticket in frequent flyer
update"
... when looking for a sticky wicket we updated it so it is now
a parent traveling with their child without their spouse
... where they need a credential that the other parent has
given the parent permission to travel (typically done with a
notarized letter)
... the traveling parent has enough frequent flyer miles to
upgrade the ticket to first class, using a digital coupon
... so we have travel credentials, frequent-flyer credentials,
and the coupon
bigbluehat: we want to avoid the
need for parentage to be expressed in addition to the notarized
letter
... the system should not also have to verify each of these
points separately
JoeAndrieu: thank you for adding
that. There is back-and-forth on the right about what details
are in the notary
... If passports were smarter than they are in print, then the
indication of who is the guardian could be in the
credential
<DavidC> bye
JoeAndrieu: there is an open
question about how much innovation should go into the
credential definition themselves, or should we just model the
current credentials
... today all you need is the notarized letter
... which is an assertion that the present parent is allowed to
travel according to the parent not present
stonematt: what I'm wondering is,
first the issuer can issue whatever they want, like including
parentage
... the local regulatory body controls that, not the state
department. So there may be another credential like birth
certificate to include parents
<Zakim> stonematt, you wanted to say smart or "minor" passports?
JoeAndrieu: that sounds spot on to me
manu: I believe you already said
this, but I want to confirm. We should try to avoid smart
credentials and changing the current process or it won't seem
like a realistic use case
... the further you deviate from the paper based process, the
harder time people have seeing it as a real use case
... someone that doesn't know about the potential futures needs
to be able to see something they recognize
... so +1 to not getting super fancy, but modeling the
equivalent digital credentials to mirror current
processes
... this use case seems great, because many people could
identify with it, and nothing here sounds crazy with a good
sticky wicket
... it demonstrates a number of interesting credentials and how
they work together
<Zakim> manu, you wanted to avoid "smart credentials", which I think Joe said we're doing.
JoeAndrieu: We could talk a little about threat model, where we don't have responses written up yet
stonematt: we could introduce the construct here, as it changes the structure of the document a bit
<stonematt> jump to section 3.1.7 for discussion about Thread Model
JoeAndrieu: we have a section
called 3.6.8 for a threat model. Looking at 1.3.7 they are
pulling credentials together into a single presentation
... we have the idea we need a threat model somewhere, but it
may make more sense to have a threat model with attacks
enumerated for each use cases, and what crazy things might
happen and how the technology or the process might help us
address those threats.
... for this one, we want to consider what happens if a
terrorist tries to impersonate Sam
... we've identified two responses, and we want input from the
group on these
... so far we have "identity assurance based on presentation
and other data"
... which is desirable no matter which credentials are
presented
... next is to do assurance based on the contents of the
claims, like biometrics and other data that may not currently
be present in all credentials (though we want to echo the
physical process today)
... smarter credentials, adding attributes that can be
verified, may also help
... when you add private information in these credentials you
may increase the attack surface for the subjects of those
credentials.
... meaning the more data you have on people the more likely it
could be compromised
... we have 4 solutions - encrypt the claims, issuer encrypt
them uniquely for each verifier
... blind the claims uniquely for each verifier (a ZKP-like
apporach), or encrypt the presentation uniquely
... there is one more threat here that any of the given
credentials could be faked
... that threat is further delineated by it could be forged
using a stolen key
... also it could be forged by a bad actor within the issuer
organization
stonematt: to pull us back up a
little bit, we were debating how we render this in the
document, knowing some threats will be repeated in many use
cases and other may be distinct
... an approach we imagined is to describe them in each section
and then a threat model response pulled out as a first class
section of the document that addresses the threats
... then we could reference that library of responses elsewhere
in the document
<stonematt> ?
stonematt: so the question is how to address this content that could be duplicated or reused
<Zakim> manu, you wanted to make a note on the process -- mentioning security/privacy, rendering it in the document, etc.
manu: this is an interesting
approach. I don't recall seeing security and privacy concerns
raised in a use case documents before, but this seems like a
good way to make it clear we are thinking about it from the
beginning
... we also have security and privacy concerns in the data
model spec where more technical things can go, this idea seems
more concerned with the social
... on the item of "how do we represent this" there are two
approaches I can think of
... one is to do it with the numbers, which makes the
referencing more difficult
... the other way is some type of visual grouping within the
spec where the numbers serve more of a supporting role
... I say we do that refactoring after we find which things are
common
... one philosophy is "don't repeat yourself" the second
approach is to avoid referencing and jumping around
<Zakim> JoeAndrieu, you wanted to mention security & privacy in charter
manu: I would like to ignore the reuse topic first and see if it reveals what should be moved into a general privacy concerns section
JoeAndrieu: I want to fully
endorse the approach of not refactoring the responses right
now
... we did start copying the stuff and it seems to be making it
feel more choppy
... the charter is also very specific that we need to talk
about security and privacy in the use cases document
... we also need to ask for help creating a section that is a
gap analysis with SAML and OpenID
... no one in the use case conversation is a domain expert in
these technologies and we need help fleshing out that
section
manu: Dmitry could help us out on the OpenID thing, and I think DavidC was also very involved in SAML as well
<dlehn> preset+ David_Lehn
manu: we have a couple of other connections there
<stonematt> +1 to separate document
manu: I think this document could be a separate document rather than in-line with the use cases
stonematt: the charter invokes the need but doesn't say how we have to respond
JoeAndrieu: I would like to talk to you, manu, about how literally we have to take the charter there
manu: it is up to the group to
decide how to split up work
... if we feel like doing the gap analysis somewhere other than
the use case document, it seems reasonable to organize that as
it makes sense
JoeAndrieu: one of our questions then as the group is, "are there enough people reading the charter trying to understand this question at the stage of the use cases, or is it a separate document?"
manu: as long as the group has executed the work in the charter, I don't expect they will nit-pic the exact phrasing in the charter
stonematt: this document is
getting to be quite long. How much should we care about
that?
... should we pull back and edit out some of the stuff we've
added as we have been brainstorming through this process?
... we can address the size of the document if it becomes an
issue
... We have threat response, and a plan for gap analysis. Do we
have the content and structure to render in respec now?
JoeAndrieu: there are some flow
and content issues and we need a threat model for some more use
cases
... I think it is close, we can get there within the week.
stonematt: on that topic, I
volunteered over the week to be added as an editor of use case
docs
... to give the group an opportunity to protest
<manu> +1 to stonematt as an additional editor to use cases!
stonematt: if there are no objections, I'll be doing some work on github to get this stuff all put together
<dlongley> +1
+1 to editing
JoeAndrieu: what are the rules of the road around who is listed as an editor and who is listed as an author
liam: there is no such thing as
an author in W3C process, because it represents consensus as a
group
... so you list yourself as an editor
JoeAndrieu: right now we have three authors listed from the last version
stonematt: if they are substantial contributors they become editors?
liam: strictly speaking in the
process, the chairs get to make the call and appoint people as
editors
... the WG decides on issues and editors fold in the changes,
but with github that has broken down a bit and we don't have to
be too formal
JoeAndrieu: so I'm hearing we replace the author line and call those folks editors
(general agreement)
liam: we can also have a contributors section somewhere as well
JoeAndrieu: is there any expectation or desire to keep around old editors who are no longer editing? We just keep adding to the list?
liam: yeah
... it can help people's job hunting to point to W3C specs with
their names on them
dlongley: it is important to
capture authors on the spec, even if editors are the only thing
recognized
... they came up with many of the ideas in the document in a
significant and official capacity, even if they didn't type the
content into the document itself
stonematt: is there a preference
for author vs contributor?
... is there a better way to represent non-editorial
substantial contribution?
<cwebber2> I think respec has an author field
<cwebber2> yep
<cwebber2> there's an authors field
liam: I normally just see "editors" and if there is another credit section, it is usually listed separately as other contributors.
<cwebber2> we have a list of authors in activitypub
<cwebber2> https://www.w3.org/TR/activitypub/
liam: again we really want to
emphasize the consensus part that the whole group agreed
... we often have another section listing significant
contributors or working group members, if we list it at the top
it often means the real content starts "below the fold"
... but I don't believe there is a policy about that
<cwebber2> yes we did both
<dlongley> +1 to doing both
stonematt: there are some links
in chat about how other groups have done things for
inspiration
... the community group call is up next
... see everyone later!
<liam> or e.g. https://www.w3.org/TR/xslt-30/#acknowledgements
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/Topic Focal/Topic: Focal/ Present: Matt_Stone Liam_Quin Nathan_George Chris_Webber Allen_Brown Manu_Sporny Markus_Sabadello Dave_Longley Benjamin_Young kim_hamilton_duffy Found Scribe: nage Found ScribeNick: nage WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting 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: david davidc 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]