<manu> scribe: TallTed

Agenda review - https://lists.w3.org/Archives/Public/public-vc-wg/2018Jun/0013.html

manu: quick review of type array discussion

Introductions

Action Item Review

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

<manu> Spanton: Hi Chris Spanton from T-Mobile, mostly listening in right now, hoping to contribute more in the future.

stone: manu is on the hot seat

manu: confirming PR submission... re type expectations
... 3 things around type now under debate

<manu> https://github.com/w3c/vc-data-model/pull/189

manu: mostly PR #189
... 2 appear done; last one in progress

stone: what's status of attachment use case?

manu: one is fairly ready, a couple new things have been raised

<manu> https://github.com/w3c/vc-data-model/pulls

quick PR review

<manu> https://github.com/w3c/vc-data-model/pulls

<manu> https://github.com/w3c/vc-data-model/pull/189

<manu> https://github.com/w3c/vc-data-model/pull/191

manu: PR191 is about changing purpose of ID property, in verifiable presentation
... re issue 149

<manu> https://github.com/w3c/vc-data-model/pull/192

manu: PR 192 about changing `issues` and `expires` property names

<manu> https://github.com/w3c/vc-data-model/pull/185

manu: also PR 185, about disputed credentials
... not editorial, but minor

stone: on PR 192 (fixes issue 184), do we handle requiring that issuance be in past?

manu: believe so, related to checking expiration

Attachements

manu: desire seems to exist to attach arbitrary content to a credential
... generic property is being proposed. this is fraught with potential for misuse/overuse
... we already support specific sorts of attachment (e.g., evidence, terms of use)
... should probably be handled as extensions instead, which might become a core property later

<stonematt> ?

manu: another part of attachment discussion involves how to sign the expression at the end of a link (?)
... suggestion is again to aim for implementation as extension

stone: to clarify... extension would become a new context?

manu: yes

stone: related to discussion of how you reference another verifiable claim?

manu: yes, basically this ties into the idea of Linked Data; already baked into spec, but not necessarily apparent to all readers

stone: is this handled by JSON?

manu: JSON-LD delivers the distant linking; raw JSON may not handle the specifics here

liam_: security focus may not be OK with open-world style

manu: thinks that security concern is handled through sub-specs, e.g., extensions, which add to the overall verifiable credentials data model without being in the core...

TallTed: concurs

<stonematt> +1 to idea of "sub-specs"

<Zakim> manu, you wanted to respond that that is handled through subspecs.

manu: specific applications might be more limiting than the overall model

liam_: yes, that satisfies

manu: proposal is to put in PR clarifying how to do all this

old issues

<stonematt> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

Old issues https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

stone: many of these have assignees (including me); they all need some attention/update
... call for thoughts on addressing them... any objection to last-updated through latest?

[no objections heard]

stone: issue 70 -- Holder Bundling of Separate Claims -- https://github.com/w3c/vc-data-model/issues/70

manu: believe can already do this in current data model, with verifiable presentation
... reading ... concern is about issuers preventing certain kinds of rebundling ...

JoeAndrieu: this isn't really preventable; the solution is to verify the individual credentials/claims upon receipt of a bundle
... bottom line, people can lie

manu: general strategy is that preventing rebundling claims is best handled by issuing a signed credential that includes all the non-separable elements
... ZKP can be used to sign each individual element that matters

JoeAndrieu: that makes sense. I can bundle anything, but the bundled elements need not be atomic.

tzviya: it would be informative to include the negative scenario in the use case document

JoeAndrieu: +1

<manu> +1 to transfer to use case repo

<manu> TallTed: In a large part, this is incumbent on the verifier of a claim. if it matters to you, explicitly that this entity is a professor in X department, then those are the things you need to check, regardless of what credentials you're given.

<manu> TallTed: The fact that I'm associated now, or was, does not mean right now... you ask for claims that matter and verify those, doesn't matter if unrelated claims are made.

<stonematt> https://github.com/w3c/vc-data-model/issues/68

[ discussion of long thread ... whether PRs and other handling have addressed it all ... confirmation pending]

stone: 3 Types of Claims - https://github.com/w3c/vc-data-model/issues/47

JoeAndrieu: seems to be about "what does it mean, to sign a credential?"

manu: we have a proof-purpose now in [?] spec (distinct from VC data model), may address this
... we don't mention the proof-purpose anywhere in VC data model. could perhaps add this?
... this issue is a year old, probably have to loop back to see whether the issue persists or has been obviated

stone: Add renewalService URL to standard data model - https://github.com/w3c/vc-data-model/issues/19

<Zakim> manu, you wanted to note this is an important one.

manu: this is important, should go into 1.0 spec,
... drivers licenses, short-lived but auto-renewing credentials, other things

JoeAndrieu: seems like different things to be addressed. driver's license ID may be perpetual, valid across all instances of driver's license; each instance of which may have limited duration (e.g., 2-3 years)

<Zakim> manu, you wanted to suggest refreshService and its complementary to what JoeAndrieu said

manu: looking at TTL, issue#164, sees connection...

<JoeAndrieu> +1 to privacy issues for long-lived credentials

<stonematt> +1 to privacy - thar be dragons

<JoeAndrieu> "refresh URL" to be triggered by Holder's user agent "automagically"

<JoeAndrieu> that's an interesting idea

manu: we imagined that renewable credential with refresh URL might let you get fresh credential if existing credential has expired; had to be renewed by holder (or authorized agent), not by verifier (inherently unauthorized for this), due to privacy concerns
... "wallet" might be such authorized agent

JoeAndrieu: key takeaway I remember from previous was that the renewable thing should have the least data possible; if you need more data, you need to start with the full long-lived credential

<JoeAndrieu> s/start with full long-lived/shorter lived, more detailed/

Adjourned

<stonematt> adios

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: Action Item Review//
Succeeded: s/most/mostly/
Succeeded: s/verify another/reference another/
Succeeded: s/ask for claims/ask for claims that matter/
Succeeded: s/if claims/if unrelated claims/
FAILED: s/start with full long-lived/shorter lived, more detailed/
Succeeded: s/audios/adios/
Present: Benjamin_Young Manu_Sporny Matt_Stone Ted_Thibodeau Tzviya_Siegman Ganesh_Annan JoeAndrieu Joe_Andrieu Chris_Spanton Yancy_Ribbens dezell
Regrets: Dan_Burnett Dave_Longley David_Chadwick
Found Scribe: TallTed
Inferring ScribeNick: TallTed
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jun/0013.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: 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.)