Verifiable Claims Telecon Minutes for 2016-10-28

Thanks to Manu Sporny and Matt Stone and Drummond Reed and Shane McCarron and John Tibbetts and Gregg Kellogg for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:

http://w3c.github.io/vctf/meetings/2016-10-28/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
2016 Verifiable Claims Face-to-Face (Day Two) Minutes for 2016-10-28

Agenda:
  https://docs.google.com/document/d/1uYDRcHs_EOpJzezJerKnKT4Grni1sFLX2nRp7zlq2BE/edit#
Topics:
  1. Agenda Review
  2. Long-term Architectural Concerns
  3. Decentralized Identifiers
  4. Start of Data Model Deep Dive
  5. Data Model Deep Dive
  6. Digital Signatures
  7. Responding to Charter Review Comments
Organizer:
  Manu Sporny
Scribe:
  Manu Sporny and Matt Stone and Drummond Reed and Shane McCarron and John Tibbetts and Gregg Kellogg
Present:
  Manu Sporny, Gregg Kellogg, Shane McCarron, David Turner, David 
  Robert, Tomas Hnetila, John Tibbetts, Christopher Allen, James 
  Toozny, Scott Fehrman, Chris Webber, Andrew Hughes, Jestin 
  Hopkins, George Fletcher, John Fontana, Phil Hunt, Dick Hardt, 
  Jim Pasqual, Richard Varn, Joe Andrieu, Adrian Gropper, Dave 
  Longley, Eric Korb, Eric Somerville, Heather Vescent, Karen Marr, 
  Adam Lake, Jörg Heuer, Natasha Rooney, Drummond Reed, Timothy 
  Ruff, Jason Law, Adam Migus, Giovanna Mingarelli, Paula 
  Escuadera, Robert Bajor, Matt Stone
Audio:
  http://w3c.github.io/vctf/meetings/2016-10-28/audio.ogg

Manu Sporny: Chairs: Richard Varn, Matt Stone
Manu Sporny is scribing.

Topic: Agenda Review

Matt Stone:  We have a more technical agenda than yesterday
Matt Stone:  Focus is dig into deliverables of the charter, deep 
  dive on data model, deep dive on digital signatures, but before 
  that - have a discussion on decentralized identifiers and how 
  that might affect the work. We have some new participants today:
  ... Nathan George, Evernym
  ... Don Cameron, Shipstead - norweigian media company
  ... Peter Simpson, Evernym
Matt Stone:  Any changes to the agenda?
Manu Sporny:  We want to talk about other long term architectural 
  items
Christopher Allen:  We need to talk about other long term 
  architectural concerns
Christopher Allen:  Like same origin vs. multi origin

Topic: Long-term Architectural Concerns

Matt Stone is scribing.
Drummond Reed:  Start the discussion w/ manu's paper
  ... paper that was submitted to the "rebooting web of trust"
Christopher Allen:  Started w/ discussion about DID in prep for 
  RWoT
Manu Sporny: Privacy Preserving Identity Architectures: 
  https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/privacy-preserving-identity-architectures.md
Have 2 approaches: 1) want to replace PGP which is a store and 
  forward/async approach
Manu Sporny: New approach is blockchain that doesn't follow the 
  same patters of client/server relationship
Manu Sporny:  Browser security model today is "same origin" which 
  means one web site can't reach into another web site
Manu Sporny:  This is a good security model, but now we have 
  cases where you want to share data between sites - s
  ... "same origin" doesn't work well here
Manu Sporny:   A side affect of this approach make super 
  providers like google and facebook who can mediate the sharing
Manu Sporny:  The other approach is self-sovereign approach. 
  which should reduce the super-provider risk but there are new 
  security challenges here.
Manu Sporny:  Major concern it that the public doesn't understand 
  the risk/value of the data that they're sharing if they're in 
  control.  super providers understand the risk better
Manu Sporny:  Credential providers have to have a robust IT 
  infrastructure b/c inspector will continuously come back to 
  verify it.
Manu Sporny:  Example community college - what if the college 
  goes away?
Manu Sporny:  In self-sovereign, the infrastructure isn't 
  necessarily required.
Timothy Ruff:  Is there evidence that people don't understand 
  what theyr sharing
Manu Sporny:  Yes, there's evidence that people are easily fished
Christopher Allen:  But, MS doesn't necessarily understand the 
  impact of the CA security in the browser
Joe Andrieu:  And people don't really understand what they're 
  sharing w/ facebook
Shane McCarron:  Super provider can easily block/redirect traffic 
  to "bad actors" and known bad sites.
Christopher Allen:  NSA can review anyone that's 4 degrees away 
  from a terror suspect
Christopher Allen:  Facebook density shows that the average 
  separation is 4.3
Gregg Kellogg:  Is there a way to delegate to a mediator?
Christopher Allen:  Not sure mediator is the right idea, curators 
  would represent rules/policies
Richard Varn:  Thinking about sister, she calls the GeekSquad for 
  everything.  what's the role of the concierge service?
Christopher Allen:  Guardianship model may work?
Richard Varn:  Conservatorship is a better term - they have legal 
  authority of a subset of responsiblities
Joe Andrieu:  Does the mediator have to be there?  both Chrome 
  and Norton may warn me of a bad actor
Christopher Allen:  Must have the principle of portability.  how 
  do you export from one service/agent to another?
Richard Varn:  We haven't recognized autonomous agency.  if you 
  have delegated to a human agent, they have legal responsibilty
Richard Varn:  What about automation?
Christopher Allen: 
  https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/privacy-preserving-identity-architectures.md
Adrian Gropper:  Harvard law published a paper about information 
  fiduciaries - saying that this is law that ought to be made but 
  isn't settled
Drummond Reed: "Information fiduciaries" is a very interesting 
  concept
Christopher Allen: 
  https://balkin.blogspot.com/2014/03/information-fiduciaries-in-digital-age.html
ShaneM, you wanted to talk about regulatory issues
Christopher Allen: 
  http://lawreview.law.ucdavis.edu/issues/49/4/Lecture/49-4_Balkin.pdf
Adrian Gropper:  Build, run, outsource are the ways uma talks to 
  it
Drummond Reed: I think the self-sovereign identity community 
  should investigate that - ironic that it wasn't discussed at 
  Internet Identity Workshop this past week
Shane McCarron:  Need to find an approach that doesn't prohibit
Manu, you wanted to note that this stuff can be sorted out in the 
  market - verifiable claims repository enables this functionality.
Shane McCarron:  But regulatory issues aren't our remit.
Manu Sporny:  Our specs must enable the "right thing to happen to 
  happen"
Adrian Gropper: 
  http://www.theatlantic.com/technology/archive/2016/10/information-fiduciary/502346/
Timothy Ruff:  If less sophisticated people can be fooled, a 3rd 
  party is required - alternatively a protocol may work
Richard Varn: A third party may not be required, but some will 
  want it as an option and we cannot preclude that
Timothy Ruff:  The protocol would support a trust list that would 
  serve to protect the less sophistocated individual
Christopher Allen:  We're enabling the ground work for a 
  protocol, but we don't have that in our charter now.  it's hard 
  to communicate, everyone is stupid, look at how many just click 
  through, and this will just be worse.
Christopher Allen:  Asserts that they could have done better, so 
  if falls to the individual
Drummond Reed:  The concept of a decentralized internet is a big 
  shift - it's EXTREMELY threatening to the powers that be on the 
  web today? [scribe assist by Manu Sporny]
Drummond Reed:   Is that something we are dealing w?
Richard Varn:  Sometimes we have these kinds of discussions.  we 
  don't think a standard should favor or assume a market fit
Drummond Reed: "A standard should expand market opportunities" 
  <== yes
Christopher Allen:  Historically, the standards process has been 
  used to advantage a particular group
Richard Varn:  But this group doesn't want that...
Manu, you wanted to say why this is not necssarily a protocol 
  solution and to note t ime
Gkellogg, you wanted to discuss chain of trust, and how a user 
  can trust an issuer
Gregg Kellogg:  We come up with these sorts of issues fo trust - 
  how do you trust someone new? if you trusted someone in the past, 
  can you trust them again?  not our role, but we need to speak to 
  that.
Adrian Gropper:  From patient privacy rights, dealing w/ the 
  issue of trust and dealing with individuals who don't understand 
  their risk
Adrian Gropper:  Uma, let's individuals control access and allows 
  each transaction be compared to the user's policies
Adrian Gropper:  Allows user to adopt policies from providers 
  like ACLU, patient rights, etc. that is tokenized into a rule set 
  that the protocol can inspect and enforce
ShaneM, you wanted to talk about market forces and how curation 
  services are likely to help people who are more naive than others
Manu Sporny: Zakim, close the queue
Ok, manu, the speaker queue is closed
Shane McCarron:  There are organizations that we trust as 
  consumers, we can tell our less sophisticated users who they can 
  trust.  there are a group of people who will do it themselves
Manu Sporny: Zakim, open the queue
Ok, manu, the speaker queue is open
Christopher Allen:  Also recognize that centralities emerged 
  because we tried to decentralize things.  the market forces bend 
  toward centralization
Christopher Allen:  Internet founders, vint cerf, TBL, see this 
  over and over again, we have to constantly decentralize
Drummond Reed:  DId discussion

Topic: Decentralized Identifiers

Drummond Reed:  Origin of the work is IIW several years ago.
Drummond Reed:  In IIWXX - collective realization that 
  blockchain/distributed ledger could eliminate the problem of a 
  central identity provider
Drummond Reed:  Christopher put up a strawman showing a process 
  that could work, then RWoT
Drummond Reed:  There were 2 people in every session from federal 
  govt.  DHS and Office of Health Care (something)...
Drummond Reed:  They suggested that DHS might start funding 
  research
DHS and the Office of the National Coordinator for Health 
  Information Technology
Drummond Reed:  Manu and christopher were connecting on VCTF and 
  connecting the dots about identity
Drummond Reed:  Christopher, manu, drummnd responed to grant and 
  won part of it, each consulting to the other.
Christopher Allen:  Pushed back with "stop talking about names" 
  which means "human readable identifier" that doesn't have to be 
  reassignable.
Drummond, you wanted to present
Drummond Reed:  ChristopherA took out the human readable name out 
  of the process.
Drummond Reed:  This is "just numbers" - not labels
Gregg Kellogg:  Wiki has taken a similar approach...
Drummond Reed:  How many google doc identifiers do you know (none 
  b/c people remember the name they give them)
Drummond Reed:  DHS = Department of Homeland Security
Drummond Reed:  Better identity management leads to better cyber 
  security
Manu Sporny: ShaneM wonders if this version of URL is the same as 
  WHATWG URL
Drummond Reed:  We need an identier that is both persistent and 
  dereferencable and MUST NOT require centralized registration
Drummond Reed:  And cryptographically verifiable!
Private permissionless blockchain model square is filled by Intel 
  Sawtooth
Drummond Reed:  Public/permissioned allows government to trust 
  the nodes and who they are
Drummond Reed:  Permissioned ledger of diffused trust managed by 
  many parties provides the baseline for banks and govt to 
  participate
Drummond Reed:  Resests censorship, etc.
Adrian Gropper:  States may write legisation that defines what 
  can be trusted that may or may not be compatible
Christopher Allen: 
  http://legislature.vermont.gov/assets/Documents/2016/Docs/BILLS/H-0737/H-0737%20As%20Introduced.pdf
Christopher Allen: "In this section “blockchain technology” means 
  a mathematically 19 secured, chronological, and decentralized 
  consensus ledger or database whether maintained via Internet 
  interaction, peer-to-peer network, or otherwise.
Gregg Kellogg:  Is there a registry of method names
Drummond Reed:  This is a consensus network/technology so will be 
  the methodsd
Manu Sporny:  Authorization IO is a DID registry
Eric Korb:  Where does that leave auth.io?
Manu Sporny:  We'd likely use make a legacy thing and migrate to 
  the new distributed network
Drummond Reed:  Reviews 5 rules for respecting privacy
Drummond Reed:  1) Allow multiple DIDs for a person 2)avoid 
  sharing keys across DID 3)don't put private attributes on a 
  public ledger b/c it's corelatable 4) avoid correlation of off 
  ledger pointers 5) use anonymous credentials when possible
Richard Varn:  Key recovery?
Drummond Reed:  It's a "should" method - early days some won't 
  have it
Drummond Reed:  This is the decentralized PKI!
Charley_ has quit (Client closed connection)
Drummond Reed is scribing.

Topic: Start of Data Model Deep Dive

Manu Sporny:  Describes overall structure of a verifiable claim
  ... A DID is a subject identifier
  ... The set of claims includes a subject identifier claims 
  about the subject, claim set metadata, and the digital signature 
  of the issuer
Shane McCarron:  The subject identifier does not HAVE to be a DID 
  - it can be any identifier
Manu Sporny: +Q
Joe Andrieu:  Asking whether there can be multiple claims
Manu Sporny:  You can have a set of verifiable claims that are 
  bound together into an entity
Manu Sporny:  It still needs to be clarified how claims nest
Manu Sporny:  All issues should be in the issues tracker
Matt Stone:  Is the idea that the third tier (the claims 
  metadata) is controlled by the issuer?
Manu Sporny:  The claims metadata is derived from the claims and 
  not strictly controlled by the issuer
Manu Sporny:  The object that you send over the wire is a 
  protocol thing
Manu Sporny:  The signature on the bottom right now is the 
  issuer's signature, but it is intended to be wrapped in the 
  holder's signature.
Manu Sporny:  But that's not intended to be called a claim 
  because that object is at the protocol layer
Matt Stone:  We have to have a name for that "bundle of data" 
  top-level object but we're not going to discuss now
Matt Stone:  Is there a difference between the "thing that is 
  shared" or the "entity"
Manu Sporny:  Let's hold off on that
Richard Varn:  We need to have basic terminology on the levels of 
  the model
Manu described the components of a verifiable claim. The claim 
  itself has an ID
Drummond Reed:  Asked what the top level ID represents
Manu Sporny:  It represents this set of claims
Gregg Kellogg:  Is it dereference-able?
Manu Sporny:  In most cases it won't be dereference-able because 
  it is private
Shane McCarron is scribing.
Drummond Reed:  That ID represents this thing.  What is it 
  called?
Manu Sporny:  It is a set of claims
  ... the reason it is called a set is because there could be 
  lots of things in there.
Drummond Reed:   Can a claim contain other claims?
Everyone: Yes
Drummond Reed:  It seems to me that the id at the top of this 
  document, identifying this whole set of claims, is to what a DID 
  ID is to a DDO.  It is what this is about.  Does that make sense?
Everyone: Yes
Gregg Kellogg:  So this could be a DDO
Joe Andrieu:   No....
Manu Sporny:  This is a point of discussion
Drummond Reed: There was general discussion of whether a set of 
  claims could be a DDO
Drummond Reed is scribing.
Manu Sporny:  A claim set MUST contain a claim component
Christopher Allen:  But if a DDO contained a claim, it could be a 
  valid claim set
Gregg Kellogg:  If the claim element contains multiple claims, 
  then it is a claim set, and we can't call it a claim set
Gregg Kellogg: Claimvelopoe for thing holding claims
Drummond Reed:  So a credential is the name for the overall 
  object being represented
There was general discussion about what the id in the claim 
  represents vs what the id on the overall VC represents
  ... Drummond wants to see the RDF graph behind this JSON-LD 
  document
Nage: asks what is necessary to test a complete claim
Matt Stone:  We dont' want every inspector to have to verify 
  every claim every time
Richard Varn:  A claim can be submitted for a group, and 
  evaluation of that claim is up to the inspector
Manu draws a diagram of the overall model
  ... the outer envelope for the VC object has been called a 
  credential, although Manu says that the security community wants 
  to change that
  ... Manu starts to draw the RDF graph of the example VC object 
  we have been looking at
Drummond got it clarified that the RDF node at the center of the 
  graph is of type "credential" but the WG agrees the name for the 
  type is going to be changed
Gregg Kellogg:  There are youtube videos that descriibe the RDF 
  data model and how it maps into JSON-LD etc. [scribe assist by 
  Shane McCarron]
John Tibbetts:  I want to recommend that we call them Credential 
  today because all the slides say Credential. [scribe assist by 
  Shane McCarron]
Shane McCarron: Secondly.... this notion of "a bus that is full 
  of people" as an example of a credential.  Claims are 
  composeable.
John Tibbetts:  Suggests that the Task Force continue to use the 
  term credential until another term is chosen
Drummond suggests (as a newcomer to the data model) that showing 
  the RDF graph is hugely important
Shane McCarron: ... It is important to realize that in some 
  collections something different happens.
Manu, you wanted to say people may not have issue
Christopher Allen:  Makes the case that the data model may be 
  overloading the top level ID for the overall credential because 
  the credential as a whole needs to be dealt with, i.e., issuance, 
  revocation, etc.
Shane McCarron is scribing.
Jörg Heuer:  We should illustrate the difference between hasA and 
  isA
Drummond Reed:  This is based on an RDF data model.  In my other 
  work the RDF is in the background
  ... I don't think we should hide the RDF-ness of the data model 
  and why that is valuable.
Gregg Kellogg:  We were nervous exposing that in JSON-LD.  It 
  turns people off
Drummond Reed:  Are the JWT folks of the world going to throw up 
  on it.  Yes they are.
ShaneM, you wanted to ask about composing a credential for a 
  single subject
John Tibbetts: +1 On drummond's comment of being upfront about 
  RDF approach
Shane McCarron:  We are proposing using an example that talks 
  about multiple people, but that's confusing. [scribe assist by 
  Drummond Reed]
Manu, you wanted to devils advocate that we may not need linked 
  data
Shane McCarron: -1 About being TOO upfront about RDF
Manu Sporny:  The use of the RDF data model is important, but if 
  we feature it too much, then it will raise too many antibodies 
  [scribe assist by Drummond Reed]
Drummond Reed:  The reason this presentation is confusing is that 
  it is unclear what the subject of the claim is vs. what the claim 
  set is.
Gregg Kellogg:  The container is of type verifiable claim....
Drummond Reed:  What a great idea.
Manu Sporny:  So call the container a verifiable claim?
Stone_: is there an example where it is not verifiable?
Manu Sporny:  We could just delete the signature key
Gregg Kellogg:  We could delete everything...  it is the metadata 
  that makes it verifiable
Drummond Reed:  What's the entity? [scribe assist by Manu Sporny]
Manu Sporny:  We will get to that
Manu presents more slides
Manu Sporny:  A context is the thing that gives specific meaning 
  to the metadata.
  ... we use linked data for the datamodel because it makes 
  merging data later really easy
Drummond Reed: Drummond suggests that you just call it the "RDF 
  umbilical cord" ;-)
  ... if it were just JSON merging two things that say "homePage" 
  you don't know about the semantics.
Gregg Kellogg:  The nice thing about context is that keys 
  dereference to URLs so there is unique meaning.
Manu Sporny:  You can express the model in a variety of syntaxes.
JSON is big now.  Something else might be big in the future.
Drummond Reed: Manu explains the reasons for using the Linked 
  Data model
Drummond Reed: By proving a map to a long-term data model, it 
  will pass the test of time
Gregg Kellogg:  Talks to the "What is Linked Data" slide [scribe 
  assist by Manu Sporny]
Gregg Kellogg:  Everything in JSON-LD represents a 
  subject/predicate/object statement in an RDF graph [scribe assist 
  by Manu Sporny]
Gregg Kellogg:  By expressing the credential and claims in RDF 
  triple statements, they can be turned into any format, such as 
  JSON-LD, but also others [scribe assist by Drummond Reed]
Gregg Kellogg:  This also enables signatures to be 
  format-independent and to themselves be part of an RDF graph 
  [scribe assist by Manu Sporny]
ShaneM, you wanted to ask about signing and how it relates to 
  graphs
Drummond Reed is scribing.
Shane McCarron:  Asks a question about signing: what are we 
  encrypting: the bytes that are the JSON-LD serialization or are 
  we signing the underlying graph
Manu Sporny:  The answer is not straightforward as you think
Manu Sporny:  We want the answer to be that we are signing the 
  underlying graph [scribe assist by Shane McCarron]
Manu Sporny:  The answer is that we sign the underlying 
  fundamental graph
Manu Sporny:  What is signed a canonical serialization
Nage: does that introduce another problem - the need to do that 
  other serialization?
Manu Sporny:  Yes, just for the signature algorigthm
Manu Sporny:  It will be handled by a library, so it will not 
  matter to most developers
Manu Sporny:  The RDF dataset normalization algorithm produces 
  the canonical serialization
Manu Sporny:  The backup, if that gets knocked out, is to sign 
  the JSON in the JSON-LD document
Drummond Reed:  What is the serialziation specified by the RDF 
  dataset normalization algorithm
Christopher Allen:  There are up to four versions of a 
  serialization that need to be signed/stored/verified
Manu Sporny:  That canonical serialization format is N-Quads
Gregg Kellogg:  That format includes several other aspects of 
  full normalization, including how blanks nodes are identified
Gregg Kellogg:  Lists the reasons for using Linked Data, which 
  uses the RDF data model
Christopher Allen:  To him, it's not about RDF, it's about being 
  able to deterministically sign graphs
Christopher Allen:  Likes the idea of not referring to RDF, but 
  to linked graphs
Gregg Kellogg:  The key thing is representing the data model in a 
  way that is independent of serialization
Gregg Kellogg:  Likes the use of the term "statements" instead of 
  "triples" or "RDF triples"
Manu Sporny:  Explained some history about how JSON-LD came to 
  use RDF, but did not originally
Manu Sporny:  "Linked Data" is the term we can use
Gregg Kellogg:  Linked Data describes data in terms of statements
Christopher Allen:  IPLD is an example of Linked Data that does 
  not use the RDF data model
Christopher Allen:  Juan Benet agrees that it's possible to get 
  quads from IPLD [scribe assist by Manu Sporny]
Manu Sporny:  IPLD can be converted into JSON-LD
Adrian Gropper:  The only place I've run into RDF in the past 
  year or so was where he needed to understand the privacy 
  implications
Adrian Gropper:  He could not figure out how to do the privacy 
  analysis "to save his life". He's worried about that same problem 
  here.
Manu Sporny:  There are multiple ways to deal with privacy when 
  using RDF. One way is to not name all the nodes, but that's a 
  very blunt instrument
Gregg Kellogg:  Skips the "What is RDF?" slide because we covered 
  it
Manu Sporny: Covered it
Gregg Kellogg:  Shows a slide illustrating how a credential in 
  JSON-LD translates into Turtle as a different serialization 
  [scribe assist by Manu Sporny]
Gregg Kellogg:  "Flattening" is a JSON-LD concept that puts all 
  the main objects at the top level. See the JSON-LD playground for 
  more.
Gregg Kellogg:  One other thing that you can do with this data 
  model is you can run inferences because it is a true semantic 
  data model [scribe assist by Manu Sporny]
Gregg Kellogg:  This becomes particularly useful when you are 
  querying the data. For example, you can ask for a credential and 
  the processor can know that a ProofOfAgeCredential is a type of 
  Credential [scribe assist by Manu Sporny]
Eric Korb:  Another example is figuring out the domain and range 
  of a claim, e.g., that an age is something a person has
Gregg Kellogg:  Offers to put up an extensive example during 
  lunch [scribe assist by Manu Sporny]
Manu Sporny: The group is breaking to get pizza
Manu Sporny: Lunch
Manu Sporny: We're back!
Shane McCarron is scribing.

Topic: Data Model Deep Dive

John Tibbetts:  We talked about formalities.  I want to talk 
  about a practical reason to use JSON-LD
  ... I work in education.  In projects at IMS Global we created 
  a VC environment and a claim that represented a record of 
  performance
  .... targeted at competency based schools
  ... most appropriate for things like MOOCs, distance learning, 
  etc.
  ... lengthy document, deeply nested.  Info about individuals, 
  institutions, and then info about each course and the 
  competencies in the courses
  ... we tried to represent things as JOTs vs VCs
  ... we couldn't get implementations to deal with large, deeply 
  netsted stucturez.
  ... so when a claim is very complex, you need to have something 
  with the horsepower to represent it and treat it in a reliable 
  manner
There is a link in the notes from a couple of days ago.
Manu Sporny: Lunch
Manu Sporny: We're back!
Shane McCarron is scribing.
One way to think about the difference between a JOT and a VC.  
  The use case of a JOT is for relatively small things.
Chris Webber:  What I want is a DDO that points to my 
  credentials.  And validate that thee holder has those credentials 
  but does not reveal information about who I am.
Eric Korb: Example of etranscript represented in JSON-LD 
  http://atlasu.us/index.php/unofficial-transcript
One reason is privacy.  Another is peer review.... we want some 
  curation.  So we need some anonymity
Manu Sporny:  We need to be careful to not push RDF and linked 
  data too much.
  ... we don't want people to not play either.
Christopher Allen:  Couldn't we push it down a layer?
Manu Sporny:  No.  We are delivering a data model.
  ... google has proven that most developers just cut and paste 
  code.
Gregg Kellogg:  And those developers have no idea that they are 
  describing things in RDF
  ... but the fact that they are allows for the population of a 
  knowledge graph
Manu Sporny:  We should be open to the concept of RDF being 
  rejected
When adding things to a credential (like an open badge) you need 
  to add a context about the claim AND you need to add a key about 
  an earnedBadge so that the information is incorporated.
Christopher Allen:  Why would you want top embed a context in a 
  scope instead of at the top level? [scribe assist by Manu Sporny]
Manu Sporny: It depends on usage.
Manu Sporny: What's the best practice?
Manu Sporny: Again, it depends.  Schema.org does A LOT of terms.
Manu Sporny: Other vocabularies are limited.
Eric Korb:  OBI for example hasa term evidence - and that might 
  collide with someone else's term. [scribe assist by Manu Sporny]
Christopher Allen:  Are there different classes of people.  
  Creators vs. composers. [scribe assist by Manu Sporny]
Manu Sporny:  If you are composing they are going have contexts 
  already.
Gregg Kellogg:  The reason to use JSON-LD is to deal with 
  conflicting terms.
Christopher Allen:  Can I countersign a composition? [scribe 
  assist by Manu Sporny]
Manu Sporny:  Sure.  well, in theory.  No one is doing it.
Eric explains some properties from the CTI vocabulary
Manu shows how to compose some claims together into a new entity
Gregg Kellogg:  The problem is that this resolves to a graph, and 
  the information about the individual credentials.
Manu Sporny:  The assertion is that "you wouldn't do that"
  ... let me put it a different way.  Jane wouold collect this 
  stuff together and ssaying this is information about me.
Gkellogg and ShaneM are confused about how composition relates 
  keys to credentials.
John Tibbetts: JohnTib now scribing
John Tibbetts is scribing.

Topic: Digital Signatures

Christopher Allen:  Been working on signatures
  ... All of this relies on digital signature tech...there are 
  tradeoffs
  ... Describe the trade-offs.
  ... Problem statement: currently difficult to express and 
  transmit proof of age.  Plus we are all on different platforms.
  ... Another problem--huge attack surface--especially on some 
  languages, platforms; e.g, Javascript
  ... Use cases: express a digital coupon or degree
  ... Use cases: enable global semantices and data merging
  ... Use cases: also meet the needs of different communities; 
  i.e., OAuth and JWT
  ... Our mission is about data model not flows.
  ... Signature for verif claim:  goes through fields of the 
  signature node.
  ... Note that the creator field may point to a particular 
  signing party (with their own public key)...we may want to choose 
  among many creators.
Shane McCarron:  Have you considered breaking up creator from 
  creator-key?
Gregg Kellogg:  In JSON-LD you can use overlapping fields.
Manu Sporny:  When signing for a particular situation ensure that 
  the bundle is tied to a domain so it can't be replayed.
Gregg Kellogg:  What of the signature node is signed.
Manu Sporny:  Only signature value is excluded for the signing
Christopher Allen:  Nonce is used for replay attach.  Optional.
  ... Signature value shown is a PIM signature.  RSA algorithm.
  ... Goes through signing of JWT
DOT <signature>
  ... Inspecting JWT.  Uses 'entityCredential' field for the VC.
  ... Large number of languages and situations.
John Tibbetts:  So, are you agreeing that it's hard to do nesting 
  in JWT? [scribe assist by Manu Sporny]
Christopher Allen:  Yes, it's difficult to chain and nest 
  signatures in JWT [scribe assist by Manu Sporny]
Shane McCarron:  Is it supposed to be isomorphic?
Adrian Gropper:  Need 2 representations of the data to preserve 
  original.
Manu Sporny:  Linked data signatures don't normalize the data.  
  JWT signing is sensitive to whitespace, etc.
Christopher Allen:  When we are working grouping, we can 
  recommend approaches for linked data signatures.
Christopher Allen:  Needs a security review--but natively 
  supports JSON and Linked Data
  ... Approach #2: Use JWTs.  Plus: standard and lots of 
  libraries
  ... Drawbacks: problems with composition
  ... Approach 3: Linked Data JSON Web Tokens
  ... Compromise that is incrementally better than JWT.
  ... Problem: large and clear text not signed
  ... Our goal is verification approach.
  ... Some cases timestamps all we need.
  ... Especially with low-trust issuer
Manu Sporny: Extensions to Linked Data Signatures: 
  https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/blockchain-extensions-for-linked-data-signatures.md
Christopher Allen:  Commissioned munge to use Bitcoin signatures. 
   They are not RSA, smaller but interesting differences.
  ... name secp256k1.  We're using a Bitcoin curve and elliptic 
  curve.  Creator is not a traditional public key.  It's the hash 
  of a public key.
  ... CanonicalAlgorithm uses RDF normalization.
Manu Sporny:  Defining a new signature algorithm is simple.  Just 
  3 values: canonicalization, digest, signature.
  ... Other thing was blockchain anchoring.  How to do 
  timestamps.  In addition to signature info add a publication 
  proof.  Merkel tree of everybody who wanted document signed in 
  Bitcoin.
Drummond Reed: Cost of anchoring signatures in blockchains may be 
  a real issue
Drummond Reed: Both in terms of time and actual financial cost
(Thanks Drummond)
MerklePublicationProof to fully verify.
Proves not only signed by person but at a particular time.
Manu Sporny:  Use case large cache of diamonds to 
  exchange--useful to resolve escrow issues
Christopher Allen:  Someone has signed code and signature was 
  stolen and new vulnerable code is created.  Therefore, signing 
  time helps to resolve a bogus code change.
  ... open questions: support proof of publication in signature? 
  blockchain receipts? integrate Chainpont 2.0.  Open timestamp?  
  Should we start defining APIs.
Manu Sporny:  Fun to look at clear text signatures.
Drummond Reed:  Standardizing signatures is a signature issue not 
  VCTF issue.
Manu Sporny:  Typically linked data signatures (LDS) is an IETF 
  issue.
Eric Korb: https://web-payments.org/specs/source/ld-signatures/
Christopher Allen:  Before SSL there was a patent holder.  Then 
  microsoft proposed PCT.  Then SSL3.0 came out.  Went to 
  informtion draft to working group.  Took 3 years.  Possible we'll 
  get it going, try lots of stuff, after some arm-twisting we'll do 
  vctf as an informational draft.
Drummond Reed:  Will VCTF have normative reference to signature?
Manu Sporny:  Can't.  thinking is we can include JWT signing that 
  could be normative.
Manu Sporny:  New ecosys with dids, signatures, etc we'll have to 
  be careful.
Christopher Allen:  Maybe we can do some 'graph' approach (not 
  RDF) approach.
Manu Sporny:  Sigs defined now for three algorithms.  have to 1) 
  express as graph 2) normalize and 3) sign.
Chris Webber:  We can run alternate signature algorithms through 
  other standards groups.
Gregg Kellogg:  Composition signature problem? [scribe assist by 
  Manu Sporny]
Drummond Reed: I'd like to understand the composition signature 
  problem
Adrian Gropper:  Identity container level  looks like UMA and 
  JWTs
Manu Sporny:  JSON signature.  UMA focussed on JWTs.  Some think 
  of 1 api to access containers.  Also another protocol from web 
  payments for creating and sending web payment.  Payment app is a 
  wallet.  APIs for other identity containers coming from multiple 
  sources.  Many thinks there isn't a unified identity container 
  for some time.
Manu Sporny:  If people reject linked data we could use json 
  signature format.  Then compatible with UMA.
Chris Webber:  All of json canonicalization approaches are 
  without syntax.  Simply sorted within equal levels with 
  lexicographic ordering.
  ... it's json tidying up.
Gregg Kellogg:  Suggestion sign claims in an entity into their 
  own named graph
Manu Sporny: Rather than leaving them in the default graph.
Manu Sporny:  Issue of jwt: problem nesting or chaining jwts.
  ... ends up with big list of signatures that doubles data 
  everytime.
Manu, you wanted to talk about identity containers
Drummond Reed: Wait a minute, how can a signature sign the 
  signature field? Doesn't that create a recursion problem?
Adrian Gropper:  Tying verifiable claims to JWTs will be pyrrhic 
  victory.  everything needs to be tied to a standard.  we can't 
  introduce a contingency we don't need.
Manu Sporny:  For the openid and jwt people there's been strong 
  support for using JWTs
Gregg Kellogg:  Working group has to provide use cases and see if 
  jwt can handle it.
  ... maybe a json signature is more acceptable because it's 
  based on json.
  ... eric: does it solve the problem.
Assaf: who gets to choose signature method?
Manu Sporny is scribing.
Christopher Allen:  Working group can put forward list of 
  signatures.
  ... each approach has disadvantages and political risk.
Eric Korb:  We need interoperability at some point, so how do we 
  get there?
Eric Korb:  OpenBadges isn't a standard in the formal sense, but 
  may people are using it, perhaps that should be our approach.
Drummond Reed: Drummond's point is that interoperability on 
  signatures could be a matter of defacto standards rather than 
  dejure if necessary
Christopher Allen:  We want to be able to create 
  validators/proofs w/o PII - that's a dream goal, but I'd like to 
  be able to make sure that each of you can accept non-personal 
  information as an option.
Christopher Allen:  If we can get the developers doing it, 
  they're going to do what happened at Google... get developer 
  adoption first.
Drummond Reed:  We can still achieve interoperability w/o having 
  a standard first.
Assaf: What about multi signatures and self-verifiable claims - 
  is that a focus?
Christopher Allen:  I'm working on that, very explicitly.
Christopher Allen:  Selective disclosure is hard... I don't think 
  what we're doing will preclude us from that.
Christopher Allen:  Collecting funds from a variety of parties to 
  try and support some indie developers - Spec Ops or otherwise to 
  start coding this stuff around Bitcoin curve.
Christopher Allen:  If you are interested in being a recipient or 
  contribute to those funds, let me know.
Adrian Gropper:  If there is some way that patient privacy rights 
  can formally help this process without having to spend money - 
  we're all volunteers - if we can influence W3C, do let me know.
Giovanna Mingarelli:  I'm an entrepreneur, rewarding people for 
  completing positive actions, verified owner profile, we want 
  people to own their data. We'd be happy to be used as a test 
  subject for what we're talking about. Launching in January.
Drummond Reed:  What kind of verified actions?
Giovanna Mingarelli:  It's a mobile application for Androind and 
  iOS, invites tweens and millenials to track positive actions... 
  each action has a QRCode... recycle, take a pic, then verify that 
  action has been completed by a peer. It's gamified experience.
Giovanna Mingarelli:  Once you've completed the action, verified 
  that it's done, get $5 off cell phone bill for recycling, match 
  brands w/ like interests. Ownership of data is important to us, 
  if you don't want a brand reaching out to you for a gift, that 
  shouldn't happen. We still have quite a few questions, been 
  working on this for 5 years, pilot, beta, launching w/ 
  President's inauguration dinner.
Giovanna Mingarelli:  Sustainability, Civil Engagement, designed 
  as a mainstream social network but with verifications. It's meant 
  to be fun, making that process fun is hard, make it a simple 
  process, that creates a lot of data, we run the data through 
  machine learning algorithm, project  - what does a verified 
  profile look like, social linked in - data profile of who you are 
  by what you do. Essentially, combinging everything that we're 
  working on over last few days. We're ve
Ry open to templating, piloting, etc.
Giovanna Mingarelli:  It's called MC2 - action network
Drummond Reed:  So you could be a poster child for what we're 
  doing here?
Gregg Kellogg is scribing.

Topic: Responding to Charter Review Comments

Manu Sporny: 
  https://lists.w3.org/Archives/Public/public-webpayments-comments/2016Oct/0031.html
Manu Sporny:  Reiew’s tantek’s feedback.
  … Chris Wilson from Google and Mike Champion from Microsoft are 
  also looking for implementations and more concrete deliverables.
  … We have documented commitments to implement; they’re just not 
  seeing it.
  … Also, why do we need a working group? Why not keep 
  incubating.
  … Mark Nautingham also +1’d
  … We have several implementation commitments from people in 
  this room, who will respond independently.
  … If LRNG, Lumnia and other organizations that are actually 
  using the technology chime it, that will help a lot.
  … That’s fairly easy to do it. They’ll respond with who is 
  really important.
https://w3c.github.io/webpayments-ig/VCTF/implementers/
Matt Stone:  Might be interesting to take the list ^^^ to see 
  what stage they’re in (promise or in-flight)
Shane McCarron:  Spec Ops has promised to do pieces of this.
  … We need a standard to prevent lack of interoperability.
Manu Sporny:  That’s the second point: why do you need a WG. 
  Because of interoperability.
  … Government work needs to use this and needs standards to 
  reference.
Drummond Reed:  Quoting: “Before it’s claimed to the contrary, 
  this should not be understood as lack of support, but that we 
  don’t want to create eco-systems, but support those which 
  develop”
  … When you show up with paved cow-paths, then it should be 
  clear that we’re not creating something out of whole-cloth.
Manu Sporny:  We seem to have concencus on the response; 
  implementors will step forward to claim their implementations and 
  why it’s inappropriate to standardize.
Chris Webber:  Quotes from his note, rather blisteringly.
Manu Sporny:  Next couple of weeks we’ll start up weekly meetings 
  again.
Shane McCarron:  Is there a standards track for DiD?
Christopher Allen:  It’s under discussion: Kantera, OASIS, or a 
  commons organization.
  … They all have tradeoffs. It seems premature right now, as 
  backoff is required.
Adrian Gropper:  I’ve had the same converation about there HEART 
  should be fostered. It’s in the OpenID foundation, but should 
  move.
Christopher Allen:  There’s beginning to emerge decentralized 
  development; it’s all in GitHub and PGP committed. Everything 
  comes wiht consent agreements. This gives many of the benefits of 
  standards organizations, except with individual rather than 
  company commitments.
  … Other organizations devolve the standards requirements.
  … MIT Media Lab is one part contributing to BitCoin core, with 
  some part-time commitments.
  … They have their own take on Open Badges, but fundamentally 
  block chain. They love DiDs and block-chain.
Adrian Gropper:  There’s also people in Main Data Networking 
  (IPFS like). They’re funded by the feds for similar reasons.
Christopher Allen:  There will be a review on some of the work 
  done under grant by Digital Baazar and Drummond’s company.
  … There’s another fund for academic/comercial cross-work.
  … This would be a different group if GDPR people from europe 
  were involved.
Drummond Reed:  If you’re in europe, and subject to GDPR, you 
  must be auditable or suffer a 4% penalty.
  … Could be called Verifiable Claims for Employment Act.
Joe Andrieu:  If we don’t become a WG, not sure what the future 
  is, but the work need to happen.
Manu Sporny:  W3C TPAC is in Burlingame next year. They have an 
  unconference setting, so that is a way to bring things up.
Matt Stone:  Thanks for the great meeting everyone, next meeting 
  is online, next Tuesday, same time.
End of Meeting

Received on Tuesday, 1 November 2016 01:06:00 UTC