<burn> rrsgagent, draft minutes

Agenda review, Introductions, Re-introductions

<burn> scribenick: Allen

<liam> scribe: Allen

Dan reviews today's agenda as described in email. Updated use cases to be redescribed.

Dan introduces Tim Tibbals.

Tim Tibbals, Bes Innovation stepping in for John Bestt.

Works on CU Ledger, and Markus on ID.

Action Item Review

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

Dan: action item review.
... 2 open issues. Hasn't heard back from R. Varn.
... issue 57.

David to give update. Mailed out new new diagram. Attached today to PR.

<burn> s/Issue 57/Line 37/

Dan Comments?

Dan: Need anything else. Colosed?
... Closed!

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

Dan: Next item, assigning wonders to unassigned issues.
... No new issues.
... Good sign, bad sing? Soon to do new detailed review.
... Manu took editorial issue.

PR review

Dan: on to main topic of the day.

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

Dan: new topic == Pos, starting with PR 179.
... likely to get more discussion.
... Still discussion and comments.
... Manu generated issue based on Allen's comments.
... loks editorial but not entirely.
... unverifiable credentials source of contention? Manu says yes.

Man: Quick background. Allen did complete review, raising issues. 90-95% editorial. PR on new section on types.

Manu: People interleaving comments on two Pos. 177 and 179.
... question to chair about mixing 177 and 179.

Dan: Anything major in 179 other than types? If not, will move to 177.

David Chadiwick: trusted / untrusted part of discussion.

<dlongley> i didn't see anything major .. types+unverifiable/verifiable language was the only controversial part.

Manu: Many of Allen's questions related to types. Restrict 179 to editorial editors. Consider types in 177. If ok with David will switch that to 177.

Dan: one more check. No more major concerns according to Manu. Other issues regarding 179? Moving on to 177.

<Zakim> manu, you wanted to provide background on #177

<manu> this issue was raised by DavidC, which is related to 177: https://github.com/w3c/vc-data-model/issues/178

Manu: 177 new section. Added new section on types motivated by Allen' comments. David C raised issue regarding unverifiable types. Last week's call mic VCs always be verifiable. Discussion inescapable. DaveC DaveL raised concerns over current direction.

Resolve difference on this call -- Manu.

Manu what do you call a VC without proof.

Manu: Don't talk about VC without proof. May allow if proof can be established by other means.
... Based on the yes or no on previous should there be +V -V or just credential with or without proof.
... If we just say credential will be annoying to others.
... Should we just have credentials with or without proofs.
... Decide today

David: Okay with +/- proof. Error last week in talking about back channel. Whether you have authenticated channel or not independent of trustworthiness of person at end of channel. In our trust model the user is untrusted.
... Even if channel is trusted user isn't.

<Zakim> manu, you wanted to agree

David: Only way is for the issuer to use trusted channel. Thus when credentials are ferried they must always he verifiable.

Manu: agrees with David. Spec will support credentials w/o proof.

<burn> DECISION: specification will support credentials without proof

Manu: type is VC or Credential. VC without proof is logically unverifiable. Data model with or without proof.
... Just say credential with or w.o proof is cleanest approach but upsets others who say credential is user name and PW.
... In the past when we have please others we inevitably accepted their ire.
... we'll distinguish between 'credential' and 'verifiable credential'. That's the proposal for WG's consideration.
... remove other types and go with with David's suggestion to accept trustworthy channel.

<dlongley> +1 that is originally how it was implemented too

Dan: agrees with proposal. Original document had credentials and verifiable credentials.
... Did not understand that there was still external objection to credential usage. Manu to explain why that is the case.

<dlongley> "IdentityCredential" "AttributeCredential" ... are other ideas.

<dlongley> to make it clear that these are about identity not authorization

<Zakim> manu, you wanted to specify why "Credential" might be problematic.

David 2 points Agrees that credential is a much broader term. Includes UNs and PWs. VC clearly distinguished from credential. 2nd point is that there should not be an outside channel. We always go through holder.

Manu: Responding to David. There isn't pushback right now on "credential" pushback is due this being W3C standard. People could interpret it as related to other uses of credentials. Possible to do those things in the data model. No current suggestion on how actually to do that.

Manu has no strong preference between straight credential and verifiable credential. Verfiable credential fine except for absence of proof. Attribute credential interesting but new.

Manu: Still may be problem later on.

David: Says credentials will always have proofs when they leave issuer. Will insurer ever be transferring unverified credentials.

<Zakim> manu, you wanted to note that we're back to square one.

Manu: thought proofs were optional. Spec specifically talks about unsigned credentials. Perfectly reasonable not to have proof. If David disagrees needs debate.

David: has not problem with credential without proof but is a transient state. Issuer will only ever issue VCs.

<Zakim> manu, you wanted to say ok, I think... what about self-issued credentials?

David: Issuer issues to holder not to verifier. All issued credentials should be verifiable.

Manu: David's scare is about protocol not about data model. What about self issued credentials.

<dlongley> i.e. holder playing the role of issuer

Manu: Not capable of issuing key pairs. Useful to send credential even if can't sign.
... Need to have separate discussion so that we can get on to other items.
... Says we can declare it to be a protocol discussion.

<dlongley> i agree we are talking about different issues

David says we need another section about self issued credentials. Manu agrees but says it's a different PR.

Manu to take action.

Dan pauses to allow Manu to document in IRC.

Dan asks if Thea or Joe can give update on use cases.

<manu> ACTION: Manu to clarify that VerifiableCredential in the specification may or may not have a `proof` property. Remove "UnverifiableCredential", do not use "Credential" in the specification.

Will not get use case doc update today so we can discuss PRs. Go to 177.

<manu> ACTION: Manu to update data model to suggest that trust model needs to be updated for unverifiable credential.

DaveL presentation has same problem as credential. Presence or absence determines verifiablitlity

Dan other comments?

Manu: Says stay consistent cay VC and VP -- meaning specific type of presentation. Push back?

<Zakim> dlongley, you wanted to ask did we agree to use "VerifiableCredential"? (i didn't realize that was the outcome)

DavidC: Happy with VP. Finish Vp then on to other types.

<burn> I thought we agreed to 'Credential' and 'VerifiableCredential'. I didn't understand us to have backed out that agreement.

DavidL had not realized conclusion of VC. Seems awkward. Understands background. No suggestion for "generic" credential. External pressures don't generally work out. Wee verifiable credential versus claim.

DavidL attribute or identity information different from authorization information. We don't have really good choice between 2.

<Zakim> manu, you wanted to suggest VerfiableCredential and VerifiablePresentation

Dan: A little confused as to where we are on VC versus C. Manu go ahead.

<dlongley> -1 to mix and match regardless

Manu: We have only VC and VP -- No C or V. Let's be consistent and be specific. May be less specific later. VC and VP may or may not have proof.

<DavidC> +1

<JoeAndrieu> +1 to two types: "Verifiable Credential" and "Verifiable Presentation"

Nathan: Likes Manu's proposal. Subtractinv "V" causes problem with cryptographers. Presentation is occupied turf.
... Have proposed using credential and certificate. Restrict scope to verifiable keeps us away from conflicts.

<dlongley> +1 to avoiding all the bikeshedding and political issues (why i said i can live with something that isn't "data model pure") ... i.e. VerifiableCredential and VerifiablePresentation are acceptable to me, despite not being perfect

<cwebber2> I like certificate, but know based on ocap-ld experience that many are wary of association with "Certificate Authorities"

<cwebber2> and also I'd like to avoid naming bikesheds :)

Dan: Doesn't see disagreement with Manu's proposal. Disagreers should enlist on Q.

<cwebber2> +1 to manu's proposal

Dan: We have agreement. Manu to make proposal precise.

<manu> ACTION: Manu to update spec language to use "VerifiableCredential" and "VerifiablePresentation" throughout... no other types related to those concepts should be introduced.

Dan: Waiting for decision to be documented.
... Note specifically that isolated terms C and P not to be used. Manu says yes.

<manu> ACTION: Manu to ensure that spec language notes that `proof` may or may not be attached to "VerifiableCredential" and "VerifiablePresentation". Specifically, the isolated terms "Presentation" and "Credential" WILL NOT be used.

Dan: anything else on PR177?

DavidC: Related to other types. When VC is further colorable where terms of use are not so colorable. Inconsistency between VC, VP and terms of use.

DaveL relationship between VC and ToU. ToU as a type is not colorable.

DavidC says VP is similar.

DaveL VC calls out that there will be a claim. VP says there will be credentials and proof. Might be no credentials. Type information seems to communicate something with VPs not with TOU

David Says type is embedded in VC.

DaveL unknown what one find

DaveL type gives no information.

<Zakim> manu, you wanted to propose that I put a class="issue" on this so we can pull in the PR?

Manu: Marke as issue. Add DavidC's proposal but mark it as an issue. Objections? None!

Dan: Allow us to merge 177 after changes made. Manu agrees.
... Last minute comments?

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/sorry, probably shouldn't have done that//
Succeeded: s/:D//
Succeeded: s/Scribing//
Succeeded: s/TIbbles/Tibbals/
Succeeded: s/Dar/Dan/
Succeeded: s/Bes/Best/
Succeeded: s/TIblles/Tibbals/
Succeeded: s/C Leger/CU Ledger/
Succeeded: s/its/item/
Succeeded: s/Barm/Varn/
FAILED: s/Issue 57/Line 37/
Succeeded: s/Manu;/Manu:/
Succeeded: s/10 177/to 177/
Succeeded: s/Man:/Manu:/
Succeeded: s/we'll say credential with or without proof./we'll distinguish between 'credential' and 'verifiable credential'./
Succeeded: s/Dan was gong to ask the question.//
Succeeded: s/Dan not on agenda/Will not get use case doc update/
Present: Dan_Burnett Allen_Brown Tim_Tibbals Chris_Webber David_Chadwick Nathan_George Dave_Longley markus_sabadello Joe_Andrieu Liam_Quin Manu_Sporny Adrian_Gropper
Found ScribeNick: Allen
Found Scribe: Allen
Inferring ScribeNick: Allen
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018May/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: 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.)