- From: <msporny@digitalbazaar.com>
- Date: Mon, 31 Oct 2016 21:05:30 -0400
- To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
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