<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

update on PRs

<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

Focal Use Cases

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.)