Guidance on securing application/credential+ld+json with "authorship that can be cryptographically verified."
#51
Conversation
OR13
changed the title
application/credential+ld+json with "authorship that can be cryptographically verified."".application/credential+ld+json with "authorship that can be cryptographically verified."
|
|
||
| <section> | ||
| <h2>Securing JSON-LD</h2> | ||
| <section> |
There was a problem hiding this comment.
| <section> | |
| <p>Enabling the use of semantics through [[json-ld]] to describe credentials is highly desirable for many use cases. The following items cover methods of allowing semantics to be present, but to utilize common signing approaches rather than requiring transformation of the content prior to signing.</p> | |
| <p>This means that the underlying `n-quads` are not signed, and the user should be aware of this, in the event that what they wish to sign is a semantic representation of the data, rather than the data itself.</p> | |
| <section> |
There was a problem hiding this comment.
Can I resolve this comment?, seems we have found a better place to state this.
There was a problem hiding this comment.
@OR13 — Can you provide a link to that better place/statement?
There was a problem hiding this comment.
+1 to a link ... and wherever that is, instead of saying "transformation of the content prior to signing" we should say "transformation of the content via canonicalization prior to signing" ... since the content will, in fact, be transformed prior to signing, but only by cryptographic hash.
We should also not say that the following items "cover methods" but rather "are methods"... wherever we're making these statements, so as not to preclude future / alternative methods.
There was a problem hiding this comment.
See this comment: #51 (comment)
Basically, this document is not a good place to do this constraining, or talk about nquads, instead we should try to constrain the media type in the document that registers it... which is the core data model.
This document just refers to the core data model content types when securing them, best to not describe what data integrity proofs do here... since we are not using them here.
There was a problem hiding this comment.
On a related note, we talked about using this spec to "forbid proof" in the case the core data model allows it in credential+ld+json...
I think it is best for JWT representations to treat the header and claim set as JSON, and not do anything specific to data integrity proofs or any other JSON or JSON-LD specific formats...
From the view of JWS, JSON can have members, and if they are not understood, they are ignored.
There should be no special "edge cases" related to data integrity proofs in VC-JWT, the perspective should be that they are just JSON, regardless of how many proof sets or chains they have.
The place to constrain credential+ld+json is this pull request or related pull requests in the core data model:
|
added a suggestion (and am happy to update it) to make it abundantly clear that this path is signing the data as it "looks" to the developer or user, which is what the avg joe/jane developer thinks they are doing with verifiable credentials This thread and others make it very clear that we should be highly explicit about what we are doing, and avoid any possible confusion regarding proofs and types. I am highly supportive of this PR, and think that it takes us in a very positive direction where broadly adopted signing mechanisms can be used but where semantics can be readily leveraged as required for many use cases and to enhance the quality of the data. |
| <p><code>content type (3)</code> MUST be <code>application/credential+ld+json</code></p> | ||
| <p>See <a data-cite="rfc9052#section-3.1">Common COSE Header Parameters</a> for additional details.</p> | ||
| <p>See <a href="https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml">Concise Binary Object Representation (CBOR) Tags</a> for additional details.</p> | ||
| </section> |
There was a problem hiding this comment.
I'd prefer direct citation to relevant specs and less rehashing them here.
@TallTed is right about omitting the `application/` prefix. Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
The issue was discussed in a meeting on 2023-02-14
View the transcript2. Content Types.See github pull request vc-data-model#1014. See github pull request vc-jwt#51.
Orie Steele: We're going to be talking about content types and media types..
Orie Steele: They typically register because they want to distinguish content... there is a registry, it has useful entries, large number of existing registry entries..
Orie Steele: media types / content types -- looking at a few specifications, you should read them... in JSON Web Signatures, content type header parameter, in JWS, header and payload, one of the header parameters can be content type... secure CSV or JSON... declare cty using media type.. Michael Jones: I'm excited about application/json because it does a lot of heavy lifting every day.. Orie Steele: one of the other places you see media types show up is in APis... developers and consumers tend to think more about APIs... APIs are a great place to see real value wrt. media types and content types.. Mahmoud Alkhraishi: What's the timeline on te proposal?. Orie Steele: This is in VC Data Model 2.0 -- has to go to CR first, that's timeline. It's up to us when it goes somewhere.... Ivan Herman: Formally speaking, W3C sends the request for media type when document is in CR, not before, right now nobody knows about this media type and won't know until we get to CR... if I'm still staff contact, this is the official process, I send it..
Michael Jones: One thing to add, it's good to send this when we're at CR because we can still make changes if IANA says we did something wrong. What we would be asking for at CR is a provisional recommendation, it does appear and it appears as "temporary"... once we have a REC, at that point we send another request to IANA to update registration from provisional to permanent..
Ted Thibodeau Jr.: One more wrinkle, because it has two plus signs at the right hand side, there is an RFC that is going through IETF, but indeterminate future, if it gets accepted then this media type is accepted, otherwise it gets rejected.
Manu Sporny: rfc for multiple pluses is in good shape and getting ready for last call.
Orie Steele: Here we have our request, one of the questions that we've been asking is whether proof is a valid/expected member of this content type..
Orie Steele: on to application/credential-claims-set-1.1+json ... maybe we want .v1+json -- those are questions, this one is requested to be registered in a different technical recommendation in our group..
Orie Steele: I'm referring to the credential-claims-set-1.1, the interesting piece is "claims-set" == in example you can see members of a payload, there's sub, jti, iat, exp, nonce -- all of those are registered claim names.... the one important to us is 'vc'.
Orie Steele: For different registry than media types, for JOSE -- JSON Web Tokens Claims registry. VC, the member of this payload, has a structure that looks like a credential, ignoring proof for a second, it looks like JSON-LD... the claim set in vc, has the same sort of thing.. Michael Jones: Some background, this term claims set is defined by the JWT specification, RFC7519 and it's just a name for the JSON that is the body of a JSON Web Token, it's a JSON object with a bunch of claim names as the field names, so iss, typ, jti, those are the claims set claims..
Michael Prorock: There are some benefits for how claims sets are registered in -- JSON tends to get verbose, standardized way to say "these are things we say all the times".... Orie Steele: Thanks for the point about the shortness, there is text that says "We like short names for payload/header" ... but why, it could be that being more verbose would be more semantically unambigouous.. Michael Jones: The reason why, JWTs can be used in browser query strings, for various reasons, there are still browser URL length restrictions that are small... 2k, 4k, 8k... It was fixed IE at one point, it's bigger than it used to be, you have systems truncating content.. Orie Steele: To make the token format, you can make a string encoding on top of another string encoding. Michael Jones: By a factor of 33% larger. Orie Steele: If these names get longer, those other names get longer, that's part of the design here. Part of the content type for the token themselves. After the break, we can see full token, token itself can be response from server, token can be encoded response.. Samuel Smith: For JSON Web Token, this would be the payload, adn then tunnelled within payload could have, content type, vc property could be JSON-LD formatted VC with proof included if proof is part of VC spec.. Orie Steele: This particular registration request is also in VC-JWT today, to describe what we did in v1.1. We are working on v2.0, but we want to be able to refer to that object in v1.1 that concretely matches, shorer arguments about what we're doing in the future.. Samuel Smith: This one is saying proof is externally attached.. Orie Steele: Yes...
Kristina Yasuda: found the statement, if JWS is present, digital signature applies to issuer... or VP ... is a holder..:
Orie Steele: It says "can be omitted", doesn't say "MUST" be omitted. What we would interpret that as is proof is optional..
Kristina Yasuda: This has caused a lot of confusion, to clarify vc claim does not contain entire VC, it only contains properties defined in VC Data Model that didn't have mapping into original JWT claims, but VC only should contain stuff about credential subject.. Orie Steele: At this point, we should read definition of credential and verifiable credential.. Joe Andrieu: I don't know if this is substantive, is type after
Oliver Terbu: More background information, proof, why it can be omitted, to use it to express proofs other than what you can express w/ JWTs... you'd have VC JWT with proof with DI proof... those are things that are not great. Discussion over last few years, JWT claims repeated... instead of vs. in addition to -- intention was to focus on small size footprint ... use JWTs in query strings, that's why we decided to do that stuff..
Orie Steele: This is probematic language in v1.1, definition of credential and verifiable credential uncomfortable and confusing to readers.. Brent Zundel: A credential is a set of one or more claims made by an issuer. A verifiable credential is (reads from spec)....
Orie Steele: What I heard Kristina to say is: This isn't verifiable, but we use verifiable name for it... there is no cryptographic authorship, this is secured with an external proof, maybe this should be called credential because it has no proof, or call it creential cause it has an external proof, but confusing ....
Orie Steele: how many media types do we have defined right now? ... 0 in v1.1, 1 currently in the proposal. Joe Andrieu: at least a 3rd media type here we should understand as a group. media type we are securing, and two that are the secured version of them. the language here mushes them all together. Orie Steele: the media type we're securing has the most consensus in the group. vc ld json. pull request 1014 is attempting to describe normative requirements for credential+ld+json. if we can gain consensus we can proceed to securing it. can be easy if the normative requirements are clear on how we do it.
Orie Steele: new things! talking about v1.1 up until now. and core data model objects (credential). now, switching to talk about other concepts - proposals. pull request recently merged for vc+ld+jwt, but no FPWD for vc-jwt. there is plenty of time to object.. Michael Jones: typ is what you would put in a browser if you were to transmit. Orie Steele: cty is about the payload alone, not header or signature.
See github pull request vc-jwt#51. Michael Prorock: a note on cty. referring to payloads is important for business logic processing. seeing this at IETF. #1014 - not whether a proof is allowed in the payload. whether it's allowed with credential+ld+json. or, should we say: if there is a proof embedded in the payload should we use a different cty to describe it, along with a different media type for the browser, etc. not saying whether you can have an embedded proof. just the rules around it.. Orie Steele: that's right. spice from the first slide!. Ted Thibodeau Jr.: editing others slides. adding the / to the cty, for both cty and typ attrs. these values are shortened because people like to shorten things. specifically to delete "application/" from the beginning. it should be interpreted as if this were present.. Orie Steele: can someone read the section that describes the removing of the application prefix? TallTed is right..
David Waite: from RFC 7515 - section 4.1.10. - to keep messages compact, recommend you omit prefix when no other slash appears in the media type value. must treat it as if there application/ were prepended... Manu Sporny: part that's concerning. can't remember having to think this hard about other media types. general concern: all media types we're considering, how will they work combinatorially? lots to understand and learn. developers will get this wrong..
Manu Sporny: "we will make important decisions around media types" -- slightly misguided. we will do our best for media types. devs will get it wrong, because it's difficult. what do we do then?. Orie Steele: the point about "going into the thing to determine whether it's secured or not" is important. one thing dlongley has been saying...can have an intermediary processing a cty that has no ability to verify - just relay. all that it's able to do is to send along a cty. don't make any intermediary responsible for parsing..
Orie Steele: what manu_ is saying: be careful writing normative requirements that mandate parsing. envs that cannot dig in won't be able to handle normative requirements. an important part of considering this..
Orie Steele: second part: as a developer. don't like being told I'm going to make mistakes, even if I know that I will make them. here for simplicity as much as we can. remember the warning from browser vendors about handling ctys. browser vendors know that mistakes will be made. they try to warn, we should too. Dmitri Zagidulin: clarifying question about what mprorock said about #1014: what is the usefulness of embedding an embedded proof json-ld proof in a JWT? what's the benefit of a proofs section inside a jwt.
Michael Prorock: there is a case I can foresee. not advocating for it. with a JWS you are not signing the same thing that you're signing with a data integrity proof. inherently signing two different things. with a JWS what you're signing is what you see (what the system sees at first glance). with a data integrity proof, signing over the semantics of the data in the credential -- signing a transformation, the nquads. different thing.
Michael Prorock: at a top level you can ask "is this data tampered with?" that's the use of JWS - the external signature. what's coming with the proof...let me run URDNA2015 and verify the signature. what that tells you is what is the intention of the semantics tied back to the vocba. was that itself modified? different than just signing the bytes.
Kristina Yasuda: 2 things - to manu_: agree we have a job to make it clear to readers which cty to use depending on which direction we want to go. to that extent, the current spec gives us those options already. heard a lot of feedback people want to do different things. codification is useful. maybe could be different than cty and typ..
Kristina Yasuda: 2nd point - reacting to mprorock -- made a comment on the PR, explanation makes me thing if we want to sign JWT with an embedded proof it should be a separate media type. could be dangerous security wise.
Michael Prorock: yes.
Michael Jones: agree with kristina. appreciate what Orie, mprorock and others have advocated. starting to separate and cleanly advocate for things that are separated but distinct. in vc 1.0 spec we had the vcdm representation of content types. now we have a media type for that. also had 1 or more jwt claim sets for vc-jwts. depending on 'in addition to' or 'depends on' option - 2.0 now codifies that. delineation is important. th.
Michael Jones: appreciate how differentiating things that are actually different has enabled us to make progress. Joe Andrieu: something to be learned/looked at for how gzip is handled on the web. not clean either. media type could be gzip, could be content encoding as gzip. in a future universe would like an integrity type. do not have a way to do that yet. stuck with multiplicity. we also have verifiable presentations. have the same multiplicity there..
Joe Andrieu: however things get secured, will need to add it for both VCs and VPs..
Samuel Smith: to Gabe's comment, there can be a way of communicating other steps. not only does the signature need to validate, there needs to be validation against some schema. additional level of validation. can be useful to constrain semantics. need some discussion of how we can convey that.
Michael Prorock: I think manu_'s on to something important. here be dragons areas. let's be careful of what we're defining and how. what do we actually mean by typ and cty? what typ is saying -- we are expecting the overall body of the JWT to be a verifiable credential and have LD (as indicated) and expecting a JWT format. what the CTY is saying about the payload -- expecting it to be a credential with LD.
Michael Prorock: this has been of the reasons I've been stubborn about 'when we start adding additional modifiers ...' many CVEs around this. openSSL had a typ confusion thing because x509 has badly handled this stuff. we should learn. even if it prevents us from doing some stuff. let's be explicit when there's a divergence.. Orie Steele: dmitriz asked the use case for proof being in claim set. mprorock answered, but want to repeat processing comment. can think of it as tunneling. I'm tunneling my embedded proof through the cty header..
Orie Steele: e.g. constrained environment. it's a good thing, can forward content with different values for typ and cty. the concept of being allowed to tunnel one security format to another is a thing we see in the wild. should be careful of how that will be interpreted by browsers. allowing for tunneling could be a thing they like or don't - let's make a case for tunneling.
Orie Steele: can close door to some use cases being affected if we do this. Dave Longley: tunneling is one of the cases, yes. have left many comments. let's only have as many media types as we need and not any more. always another place to draw a typ boundary. let's make sure the boundaries we draw solve concrete problems. e.g. places that use binary data. does not mean the same concerns will apply to a json format, parsing, or browser parsing.
Dave Longley: if we have too many media types we can have more problems for ourselves. can lead to vulns. let's have concrete examples of threads/problems we can analyze to see if we can add more media types. then we should add them. let's not jump ahead and add all the types today. can cause problems. Manu Sporny: +1 to dave. trying to see what type of problems we're solving. yes, specific media types we want in this group. nobody's saying we shouldn't have them if they're paired with a good use case, paired with good security practices. that's good - no objections heard. objection -- let's create media type patterns. we could have 20-30 media types based on these patterns, that's where I get shaky..
Manu Sporny: ... typ, yes. cty, yes. let's figure out if we want to add the word 'verifiable' in front of it. what do we want to do with the proof thing? is there anyone objecting to having the typ field (#51)?.
Manu Sporny: I expect that to happen (typ field). for a content type, that's a separate discussion. is it a subtype of credential? if it isn't there's a can of worms. see PR #1014.. Orie Steele: intention not to make any decisions during the f2f, just to inform. Brent Zundel: let's make decisions!.
Andres Uribe: considerations for using the typ parameter for the media type defined that specifies how the credential is secured? anything that has 'verifiable' should have a typ param that specifies how it's secured. does this avoid the need for cty? as someone who's coming in relatively new. very different when you talk about a verifiable cred vs cred. verifiable = must have a proof whether embedded or external. would clarify a lot for devs. Orie Steele: parameterization of media types..beginning said 'careful!' yes it's an option, can propose it on any of the open PRs. if we do that we need to describe these parameters in registration requests. less opaque. have to ask questions-is param present? what does it have? think if we can avoid parameterization we should. Mahmoud Alkhraishi: to understand...the cty saying credential+ld+json indicates to me that the object vc will or will not have a proof (determined on #1014), if not a proof, will know whether the object is signed or not based on the typ?. Orie Steele: current spec has a section called 'proofs' which says proofs can be embedded or external. one of the most confusing parts - with media types, can have a media type with an external proof. content wouldn't have a proof..
Orie Steele: jwt uses external proofs. the type vc+ld+jwt indicates the presence of an external proof. the cty param credential+ld+json (let's pretend it's verifiable+credential+ld+json), proof would be in the payload. we won't know until we constrain the payload.
Mahmoud Alkhraishi: when I'm processing vc+ld+jwt am I expected to process two signatures?. Orie Steele: that's the warning!. Joe Andrieu: advocate for parameter use. have an underlying data model which is being delivered. if we had an integrity type in the header I'd be arguing for using that. the integrity mechanism feels like a parameter to me. if we have two media types they don't have to be related at all. part of the confusion is about tunneling. the idea that you can tunnel is something we should not encourage - have to check different proofs. Brent Zundel: what decisions do we want to make here? PR #1014 proposes to say proof is not included, right?. Orie Steele: yes, dlongley and I had a discussion. he suggested proof is allowed in credential+ld+json. my original intention was to forbid that from being possible..
Orie Steele: merged that since it was within my original intention. merging intentions into PR does not mean consensus! there is currently no consensus on #1014. most accurately captured by whether the cty can have a proof in it. can make that decision today. Brent Zundel: also a decision to be made for #51?. Orie Steele: yes, for #51 we are requesting the registration for typ parameter in vc-jwt. it is JWT specific. #1014 is core data model specific.
Brent Zundel: in addition to those two decisions, what other proposals could/should be on the table for the group for the next 30m?.
Orie Steele: other proposal: application/vc+ld+cwt.. Dave Longley: we get to decide if it makes sense if squares are rectangles in this case :).
Michael Prorock: assumption from devs coming in that you're just living in a JOSE/COSE world. but have two different ways of exchanging info beyond that. if I as an issuer send this, if I believe there's a high degree of value in the embedded proof then I should signal it.. Manu Sporny: the other thing at play -- we have two different philosophies. the JWT philosophy, and embedded proof, and they don't make the same decisions. for media types let me propose we only have two media types forever: credential+ld+ and verifiable+credential+ld+.
Manu Sporny: specifically not saying it has "proof" because that's just how we do it today. I'm concerned about us fixating on whether proof is there or not, we should focus on whether there's an embedded proof or not. from the DI side there will not be a +di for a while. we won't make that decision any time soon. will wait for impl feedback.. David Waite: it is a little bit weird. the way things are structured at the JSON level are not how they're processed at the LD level, since being an RDF graph. a lot closer than you think. in my opinion, we've defined multiple proofs only in the context of the proof parameter can we have multiple values.
David Waite: the semantics of a data integrity proof and a proof inside a JWT are quite different. e.g. protecting someone else's proof with my own (today it is chains). the only interpretation I can think of is that the proofs are independent. if there are multiple, choose between them. any intermediary could remove proofs, and have no way to know that happened. Joe Andrieu: the parameter still resonates with me. not talking yet about the API used to send a proto-vc (unsigned) to be signed by another component. to me that is credential+ld+json, parameters used to specify the type of proof embedded in the VC, instead of the VC embedded in the proof.
Kristina Yasuda: reviewing document posted above (https://hackmd.io/Q8EOfbzYTZK_jHH-BJcfKA?view). Orie Steele: do not have any merges for typ in the core data model just yet. Kristina Yasuda: Manu's proposal in typ not cty.
Michael Jones: we can also provide guidance in the spec on the use of credential+ld data type if used with an external proof--must not also contain an internal proof. whereas; if used within a context with internal proofs it may contain one. that would be OK with me..
Orie Steele: [new slide - 25] Pull #51 in vc-jwt has both vc+ld+cwt and vc+ld+jwt. Andres Uribe: concrete proposal to make sure there are parameters. not just add credential+ld+json but specify how it is proved, e.g. ?proof=[jwt, cwt, etc.]. similar to what Joe was saying / and adding to Manu was saying.
Dave Longley: every VC is a C. every square is a rectangle. already have a model where you look at JSON properties - you look at the ones you understand, ignore the ones you don't. also understand whether they care about these proofs/properties. if you don't care - fine - does not mean a sender should explicitly remove it, should not need to explicitly remove it because it's there. providing guidance around processing is fine. sh.
Orie Steele: responding to dlongley. let's surface legitimate use cases. let's make sure use cases are driving our spec development. without these normative statements, we have trouble satisfying. tunneling is a real use case. "type confusion attack" mprorock mentioned. is that a concrete use case for forbidding proof being in the payload?. Michael Prorock: want to call out. parameterization - have experience around media stream handling. there is a parameterization to be had, maybe not in 2.0 but in future versions of LD. how do we indicate at the header layer what signature am I expecting? same notion of parameterization in cryptography.. Samuel Smith: one use case not seen discussed - prevalent in business/legal world: endorsements. have a party create something. other parties lend credibility via endorsements. can have threshold structures for issuance. can also have threshold structures for receiving. should support things that are really prevalent in the business world. Manu Sporny: clarification there is no +ld media type. does not exist. it is only ld+json. would need to figure out something.... Brent Zundel: Dave mentioned squares and rectangles. Let's talk about the accurate labeling of squares and rectangles.. Mahmoud Alkhraishi: had a similar question. if we separate credential+ld+json to state there will be no proof and have vc+ld+json and say there will be a proof, will allow us, when we use the cty field, if the typ field says ld+jwt, can say process the internal signature as well or do not.
Mahmoud Alkhraishi: can make it very clear when I receive a vc+ld+json I should process a proof. normative requirement would be straightforward. allows us on the JWT side to say I care or don't.. Dave Longley: if we're deciding to add a prohibitive statement let's be clear about what problem it's solving with a concrete use case..
Orie Steele: unbounded number of content types that are relevant to software development. that's why cty is liked. can treat as opaque bytes with a cty that informs the strucutre.
Orie Steele: dlongley asking for concrete use cases. proof being present in a credential. mprorock has said openSSL type confusion as an example. another place it could be a problem: if the @context returns different content than what it was when the canonicalized proof was created, the outer external proof will verify, the inner won't until the URL in the context change(s/d). Michael Prorock: two concrete problems: one - what Orie mentioned. second -- crawling and parsing massive amounts of data...what went into models...could be cases where I want to embed different types of proofs. don't want that knowledge to be confused for any of my users. e.g. for web archive, need to maintain the state of the internet at different times. how we begin to do this?. Joe Andrieu: there is an unstated presumption that's conflating the signature on a JWT with a signature on a proof. no reason it needs to be on the same issuer.. Manu Sporny: going back to what selfissued said. maybe we can add language to not outright forbid in the base class. start out with softer language in the beginning - not outright "don't do x" - then we can either go to "now it's forbidden" or we realize the guidance goes against real use cases..
Manu Sporny: where the JWT stuff can be very explicit: do not do it. the base spec can say "this is what people are expecting" . see VC-JWT for more information on this.
Samuel Smith: echo Orie's statement. if I sign a receipt. if someone purchases from me, it's signed, it has a proof. I give a receipt on the proof that I sign, referencing what they sign. liability on issuing receipt is on me..
Gabe Cohen: The use case for tunnelling, at TBD, transport credentials over DWNs. Use cases on status list, different signature methods, blob might be signed as a VC itself, might have many different types -- tunnelling is real..
Michael Prorock: different between verifiable+credential and verifiable/credential.
Dave Longley: need to know what you care about a priori. need to decide what you're verifying and make decisions there. let's make sure we know where the knowledge is coming from. verifier should know ahead of time what it's looking for and willing to verify.
Orie Steele: queued to comment on verifiable+credential or verifiable-credential - have been comments on #1014. if the dash were changed to a plus it would say there's a direct relation to credential...only a content type when ld+json, different than verifiable-credential+otherstuff. what Ted said: verifiable-credential and credential are at the same level. Michael Prorock: just do this in 'vc-jwts': if this is a W3C....we eat this up in the browser. we need to think about what I, as a browser, see application/??? - do I know how to verify it?.
Manu Sporny: all vendors support application/ld+json. tell vendors do things as you've always been doing..
|
1 similar comment
|
The issue was discussed in a meeting on 2023-02-14
View the transcript2. Content Types.See github pull request vc-data-model#1014. See github pull request vc-jwt#51.
Orie Steele: We're going to be talking about content types and media types..
Orie Steele: They typically register because they want to distinguish content... there is a registry, it has useful entries, large number of existing registry entries..
Orie Steele: media types / content types -- looking at a few specifications, you should read them... in JSON Web Signatures, content type header parameter, in JWS, header and payload, one of the header parameters can be content type... secure CSV or JSON... declare cty using media type.. Michael Jones: I'm excited about application/json because it does a lot of heavy lifting every day.. Orie Steele: one of the other places you see media types show up is in APis... developers and consumers tend to think more about APIs... APIs are a great place to see real value wrt. media types and content types.. Mahmoud Alkhraishi: What's the timeline on te proposal?. Orie Steele: This is in VC Data Model 2.0 -- has to go to CR first, that's timeline. It's up to us when it goes somewhere.... Ivan Herman: Formally speaking, W3C sends the request for media type when document is in CR, not before, right now nobody knows about this media type and won't know until we get to CR... if I'm still staff contact, this is the official process, I send it..
Michael Jones: One thing to add, it's good to send this when we're at CR because we can still make changes if IANA says we did something wrong. What we would be asking for at CR is a provisional recommendation, it does appear and it appears as "temporary"... once we have a REC, at that point we send another request to IANA to update registration from provisional to permanent..
Ted Thibodeau Jr.: One more wrinkle, because it has two plus signs at the right hand side, there is an RFC that is going through IETF, but indeterminate future, if it gets accepted then this media type is accepted, otherwise it gets rejected.
Manu Sporny: rfc for multiple pluses is in good shape and getting ready for last call.
Orie Steele: Here we have our request, one of the questions that we've been asking is whether proof is a valid/expected member of this content type..
Orie Steele: on to application/credential-claims-set-1.1+json ... maybe we want .v1+json -- those are questions, this one is requested to be registered in a different technical recommendation in our group..
Orie Steele: I'm referring to the credential-claims-set-1.1, the interesting piece is "claims-set" == in example you can see members of a payload, there's sub, jti, iat, exp, nonce -- all of those are registered claim names.... the one important to us is 'vc'.
Orie Steele: For different registry than media types, for JOSE -- JSON Web Tokens Claims registry. VC, the member of this payload, has a structure that looks like a credential, ignoring proof for a second, it looks like JSON-LD... the claim set in vc, has the same sort of thing.. Michael Jones: Some background, this term claims set is defined by the JWT specification, RFC7519 and it's just a name for the JSON that is the body of a JSON Web Token, it's a JSON object with a bunch of claim names as the field names, so iss, typ, jti, those are the claims set claims..
Michael Prorock: There are some benefits for how claims sets are registered in -- JSON tends to get verbose, standardized way to say "these are things we say all the times".... Orie Steele: Thanks for the point about the shortness, there is text that says "We like short names for payload/header" ... but why, it could be that being more verbose would be more semantically unambigouous.. Michael Jones: The reason why, JWTs can be used in browser query strings, for various reasons, there are still browser URL length restrictions that are small... 2k, 4k, 8k... It was fixed IE at one point, it's bigger than it used to be, you have systems truncating content.. Orie Steele: To make the token format, you can make a string encoding on top of another string encoding. Michael Jones: By a factor of 33% larger. Orie Steele: If these names get longer, those other names get longer, that's part of the design here. Part of the content type for the token themselves. After the break, we can see full token, token itself can be response from server, token can be encoded response.. Samuel Smith: For JSON Web Token, this would be the payload, adn then tunnelled within payload could have, content type, vc property could be JSON-LD formatted VC with proof included if proof is part of VC spec.. Orie Steele: This particular registration request is also in VC-JWT today, to describe what we did in v1.1. We are working on v2.0, but we want to be able to refer to that object in v1.1 that concretely matches, shorer arguments about what we're doing in the future.. Samuel Smith: This one is saying proof is externally attached.. Orie Steele: Yes...
Kristina Yasuda: found the statement, if JWS is present, digital signature applies to issuer... or VP ... is a holder..:
Orie Steele: It says "can be omitted", doesn't say "MUST" be omitted. What we would interpret that as is proof is optional..
Kristina Yasuda: This has caused a lot of confusion, to clarify vc claim does not contain entire VC, it only contains properties defined in VC Data Model that didn't have mapping into original JWT claims, but VC only should contain stuff about credential subject.. Orie Steele: At this point, we should read definition of credential and verifiable credential.. Joe Andrieu: I don't know if this is substantive, is type after
Oliver Terbu: More background information, proof, why it can be omitted, to use it to express proofs other than what you can express w/ JWTs... you'd have VC JWT with proof with DI proof... those are things that are not great. Discussion over last few years, JWT claims repeated... instead of vs. in addition to -- intention was to focus on small size footprint ... use JWTs in query strings, that's why we decided to do that stuff..
Orie Steele: This is probematic language in v1.1, definition of credential and verifiable credential uncomfortable and confusing to readers.. Brent Zundel: A credential is a set of one or more claims made by an issuer. A verifiable credential is (reads from spec)....
Orie Steele: What I heard Kristina to say is: This isn't verifiable, but we use verifiable name for it... there is no cryptographic authorship, this is secured with an external proof, maybe this should be called credential because it has no proof, or call it creential cause it has an external proof, but confusing ....
Orie Steele: how many media types do we have defined right now? ... 0 in v1.1, 1 currently in the proposal. Joe Andrieu: at least a 3rd media type here we should understand as a group. media type we are securing, and two that are the secured version of them. the language here mushes them all together. Orie Steele: the media type we're securing has the most consensus in the group. vc ld json. pull request 1014 is attempting to describe normative requirements for credential+ld+json. if we can gain consensus we can proceed to securing it. can be easy if the normative requirements are clear on how we do it.
Orie Steele: new things! talking about v1.1 up until now. and core data model objects (credential). now, switching to talk about other concepts - proposals. pull request recently merged for vc+ld+jwt, but no FPWD for vc-jwt. there is plenty of time to object.. Michael Jones: typ is what you would put in a browser if you were to transmit. Orie Steele: cty is about the payload alone, not header or signature.
See github pull request vc-jwt#51. Michael Prorock: a note on cty. referring to payloads is important for business logic processing. seeing this at IETF. #1014 - not whether a proof is allowed in the payload. whether it's allowed with credential+ld+json. or, should we say: if there is a proof embedded in the payload should we use a different cty to describe it, along with a different media type for the browser, etc. not saying whether you can have an embedded proof. just the rules around it.. Orie Steele: that's right. spice from the first slide!. Ted Thibodeau Jr.: editing others slides. adding the / to the cty, for both cty and typ attrs. these values are shortened because people like to shorten things. specifically to delete "application/" from the beginning. it should be interpreted as if this were present.. Orie Steele: can someone read the section that describes the removing of the application prefix? TallTed is right..
David Waite: from RFC 7515 - section 4.1.10. - to keep messages compact, recommend you omit prefix when no other slash appears in the media type value. must treat it as if there application/ were prepended... Manu Sporny: part that's concerning. can't remember having to think this hard about other media types. general concern: all media types we're considering, how will they work combinatorially? lots to understand and learn. developers will get this wrong..
Manu Sporny: "we will make important decisions around media types" -- slightly misguided. we will do our best for media types. devs will get it wrong, because it's difficult. what do we do then?. Orie Steele: the point about "going into the thing to determine whether it's secured or not" is important. one thing dlongley has been saying...can have an intermediary processing a cty that has no ability to verify - just relay. all that it's able to do is to send along a cty. don't make any intermediary responsible for parsing..
Orie Steele: what manu_ is saying: be careful writing normative requirements that mandate parsing. envs that cannot dig in won't be able to handle normative requirements. an important part of considering this..
Orie Steele: second part: as a developer. don't like being told I'm going to make mistakes, even if I know that I will make them. here for simplicity as much as we can. remember the warning from browser vendors about handling ctys. browser vendors know that mistakes will be made. they try to warn, we should too. Dmitri Zagidulin: clarifying question about what mprorock said about #1014: what is the usefulness of embedding an embedded proof json-ld proof in a JWT? what's the benefit of a proofs section inside a jwt.
Michael Prorock: there is a case I can foresee. not advocating for it. with a JWS you are not signing the same thing that you're signing with a data integrity proof. inherently signing two different things. with a JWS what you're signing is what you see (what the system sees at first glance). with a data integrity proof, signing over the semantics of the data in the credential -- signing a transformation, the nquads. different thing.
Michael Prorock: at a top level you can ask "is this data tampered with?" that's the use of JWS - the external signature. what's coming with the proof...let me run URDNA2015 and verify the signature. what that tells you is what is the intention of the semantics tied back to the vocba. was that itself modified? different than just signing the bytes.
Kristina Yasuda: 2 things - to manu_: agree we have a job to make it clear to readers which cty to use depending on which direction we want to go. to that extent, the current spec gives us those options already. heard a lot of feedback people want to do different things. codification is useful. maybe could be different than cty and typ..
Kristina Yasuda: 2nd point - reacting to mprorock -- made a comment on the PR, explanation makes me thing if we want to sign JWT with an embedded proof it should be a separate media type. could be dangerous security wise.
Michael Prorock: yes.
Michael Jones: agree with kristina. appreciate what Orie, mprorock and others have advocated. starting to separate and cleanly advocate for things that are separated but distinct. in vc 1.0 spec we had the vcdm representation of content types. now we have a media type for that. also had 1 or more jwt claim sets for vc-jwts. depending on 'in addition to' or 'depends on' option - 2.0 now codifies that. delineation is important. th.
Michael Jones: appreciate how differentiating things that are actually different has enabled us to make progress. Joe Andrieu: something to be learned/looked at for how gzip is handled on the web. not clean either. media type could be gzip, could be content encoding as gzip. in a future universe would like an integrity type. do not have a way to do that yet. stuck with multiplicity. we also have verifiable presentations. have the same multiplicity there..
Joe Andrieu: however things get secured, will need to add it for both VCs and VPs..
Samuel Smith: to Gabe's comment, there can be a way of communicating other steps. not only does the signature need to validate, there needs to be validation against some schema. additional level of validation. can be useful to constrain semantics. need some discussion of how we can convey that.
Michael Prorock: I think manu_'s on to something important. here be dragons areas. let's be careful of what we're defining and how. what do we actually mean by typ and cty? what typ is saying -- we are expecting the overall body of the JWT to be a verifiable credential and have LD (as indicated) and expecting a JWT format. what the CTY is saying about the payload -- expecting it to be a credential with LD.
Michael Prorock: this has been of the reasons I've been stubborn about 'when we start adding additional modifiers ...' many CVEs around this. openSSL had a typ confusion thing because x509 has badly handled this stuff. we should learn. even if it prevents us from doing some stuff. let's be explicit when there's a divergence.. Orie Steele: dmitriz asked the use case for proof being in claim set. mprorock answered, but want to repeat processing comment. can think of it as tunneling. I'm tunneling my embedded proof through the cty header..
Orie Steele: e.g. constrained environment. it's a good thing, can forward content with different values for typ and cty. the concept of being allowed to tunnel one security format to another is a thing we see in the wild. should be careful of how that will be interpreted by browsers. allowing for tunneling could be a thing they like or don't - let's make a case for tunneling.
Orie Steele: can close door to some use cases being affected if we do this. Dave Longley: tunneling is one of the cases, yes. have left many comments. let's only have as many media types as we need and not any more. always another place to draw a typ boundary. let's make sure the boundaries we draw solve concrete problems. e.g. places that use binary data. does not mean the same concerns will apply to a json format, parsing, or browser parsing.
Dave Longley: if we have too many media types we can have more problems for ourselves. can lead to vulns. let's have concrete examples of threads/problems we can analyze to see if we can add more media types. then we should add them. let's not jump ahead and add all the types today. can cause problems. Manu Sporny: +1 to dave. trying to see what type of problems we're solving. yes, specific media types we want in this group. nobody's saying we shouldn't have them if they're paired with a good use case, paired with good security practices. that's good - no objections heard. objection -- let's create media type patterns. we could have 20-30 media types based on these patterns, that's where I get shaky..
Manu Sporny: ... typ, yes. cty, yes. let's figure out if we want to add the word 'verifiable' in front of it. what do we want to do with the proof thing? is there anyone objecting to having the typ field (#51)?.
Manu Sporny: I expect that to happen (typ field). for a content type, that's a separate discussion. is it a subtype of credential? if it isn't there's a can of worms. see PR #1014.. Orie Steele: intention not to make any decisions during the f2f, just to inform. Brent Zundel: let's make decisions!.
Andres Uribe: considerations for using the typ parameter for the media type defined that specifies how the credential is secured? anything that has 'verifiable' should have a typ param that specifies how it's secured. does this avoid the need for cty? as someone who's coming in relatively new. very different when you talk about a verifiable cred vs cred. verifiable = must have a proof whether embedded or external. would clarify a lot for devs. Orie Steele: parameterization of media types..beginning said 'careful!' yes it's an option, can propose it on any of the open PRs. if we do that we need to describe these parameters in registration requests. less opaque. have to ask questions-is param present? what does it have? think if we can avoid parameterization we should. Mahmoud Alkhraishi: to understand...the cty saying credential+ld+json indicates to me that the object vc will or will not have a proof (determined on #1014), if not a proof, will know whether the object is signed or not based on the typ?. Orie Steele: current spec has a section called 'proofs' which says proofs can be embedded or external. one of the most confusing parts - with media types, can have a media type with an external proof. content wouldn't have a proof..
Orie Steele: jwt uses external proofs. the type vc+ld+jwt indicates the presence of an external proof. the cty param credential+ld+json (let's pretend it's verifiable+credential+ld+json), proof would be in the payload. we won't know until we constrain the payload.
Mahmoud Alkhraishi: when I'm processing vc+ld+jwt am I expected to process two signatures?. Orie Steele: that's the warning!. Joe Andrieu: advocate for parameter use. have an underlying data model which is being delivered. if we had an integrity type in the header I'd be arguing for using that. the integrity mechanism feels like a parameter to me. if we have two media types they don't have to be related at all. part of the confusion is about tunneling. the idea that you can tunnel is something we should not encourage - have to check different proofs. Brent Zundel: what decisions do we want to make here? PR #1014 proposes to say proof is not included, right?. Orie Steele: yes, dlongley and I had a discussion. he suggested proof is allowed in credential+ld+json. my original intention was to forbid that from being possible..
Orie Steele: merged that since it was within my original intention. merging intentions into PR does not mean consensus! there is currently no consensus on #1014. most accurately captured by whether the cty can have a proof in it. can make that decision today. Brent Zundel: also a decision to be made for #51?. Orie Steele: yes, for #51 we are requesting the registration for typ parameter in vc-jwt. it is JWT specific. #1014 is core data model specific.
Brent Zundel: in addition to those two decisions, what other proposals could/should be on the table for the group for the next 30m?.
Orie Steele: other proposal: application/vc+ld+cwt.. Dave Longley: we get to decide if it makes sense if squares are rectangles in this case :).
Michael Prorock: assumption from devs coming in that you're just living in a JOSE/COSE world. but have two different ways of exchanging info beyond that. if I as an issuer send this, if I believe there's a high degree of value in the embedded proof then I should signal it.. Manu Sporny: the other thing at play -- we have two different philosophies. the JWT philosophy, and embedded proof, and they don't make the same decisions. for media types let me propose we only have two media types forever: credential+ld+ and verifiable+credential+ld+.
Manu Sporny: specifically not saying it has "proof" because that's just how we do it today. I'm concerned about us fixating on whether proof is there or not, we should focus on whether there's an embedded proof or not. from the DI side there will not be a +di for a while. we won't make that decision any time soon. will wait for impl feedback.. David Waite: it is a little bit weird. the way things are structured at the JSON level are not how they're processed at the LD level, since being an RDF graph. a lot closer than you think. in my opinion, we've defined multiple proofs only in the context of the proof parameter can we have multiple values.
David Waite: the semantics of a data integrity proof and a proof inside a JWT are quite different. e.g. protecting someone else's proof with my own (today it is chains). the only interpretation I can think of is that the proofs are independent. if there are multiple, choose between them. any intermediary could remove proofs, and have no way to know that happened. Joe Andrieu: the parameter still resonates with me. not talking yet about the API used to send a proto-vc (unsigned) to be signed by another component. to me that is credential+ld+json, parameters used to specify the type of proof embedded in the VC, instead of the VC embedded in the proof.
Kristina Yasuda: reviewing document posted above (https://hackmd.io/Q8EOfbzYTZK_jHH-BJcfKA?view). Orie Steele: do not have any merges for typ in the core data model just yet. Kristina Yasuda: Manu's proposal in typ not cty.
Michael Jones: we can also provide guidance in the spec on the use of credential+ld data type if used with an external proof--must not also contain an internal proof. whereas; if used within a context with internal proofs it may contain one. that would be OK with me..
Orie Steele: [new slide - 25] Pull #51 in vc-jwt has both vc+ld+cwt and vc+ld+jwt. Andres Uribe: concrete proposal to make sure there are parameters. not just add credential+ld+json but specify how it is proved, e.g. ?proof=[jwt, cwt, etc.]. similar to what Joe was saying / and adding to Manu was saying.
Dave Longley: every VC is a C. every square is a rectangle. already have a model where you look at JSON properties - you look at the ones you understand, ignore the ones you don't. also understand whether they care about these proofs/properties. if you don't care - fine - does not mean a sender should explicitly remove it, should not need to explicitly remove it because it's there. providing guidance around processing is fine. sh.
Orie Steele: responding to dlongley. let's surface legitimate use cases. let's make sure use cases are driving our spec development. without these normative statements, we have trouble satisfying. tunneling is a real use case. "type confusion attack" mprorock mentioned. is that a concrete use case for forbidding proof being in the payload?. Michael Prorock: want to call out. parameterization - have experience around media stream handling. there is a parameterization to be had, maybe not in 2.0 but in future versions of LD. how do we indicate at the header layer what signature am I expecting? same notion of parameterization in cryptography.. Samuel Smith: one use case not seen discussed - prevalent in business/legal world: endorsements. have a party create something. other parties lend credibility via endorsements. can have threshold structures for issuance. can also have threshold structures for receiving. should support things that are really prevalent in the business world. Manu Sporny: clarification there is no +ld media type. does not exist. it is only ld+json. would need to figure out something.... Brent Zundel: Dave mentioned squares and rectangles. Let's talk about the accurate labeling of squares and rectangles.. Mahmoud Alkhraishi: had a similar question. if we separate credential+ld+json to state there will be no proof and have vc+ld+json and say there will be a proof, will allow us, when we use the cty field, if the typ field says ld+jwt, can say process the internal signature as well or do not.
Mahmoud Alkhraishi: can make it very clear when I receive a vc+ld+json I should process a proof. normative requirement would be straightforward. allows us on the JWT side to say I care or don't.. Dave Longley: if we're deciding to add a prohibitive statement let's be clear about what problem it's solving with a concrete use case..
Orie Steele: unbounded number of content types that are relevant to software development. that's why cty is liked. can treat as opaque bytes with a cty that informs the strucutre.
Orie Steele: dlongley asking for concrete use cases. proof being present in a credential. mprorock has said openSSL type confusion as an example. another place it could be a problem: if the @context returns different content than what it was when the canonicalized proof was created, the outer external proof will verify, the inner won't until the URL in the context change(s/d). Michael Prorock: two concrete problems: one - what Orie mentioned. second -- crawling and parsing massive amounts of data...what went into models...could be cases where I want to embed different types of proofs. don't want that knowledge to be confused for any of my users. e.g. for web archive, need to maintain the state of the internet at different times. how we begin to do this?. Joe Andrieu: there is an unstated presumption that's conflating the signature on a JWT with a signature on a proof. no reason it needs to be on the same issuer.. Manu Sporny: going back to what selfissued said. maybe we can add language to not outright forbid in the base class. start out with softer language in the beginning - not outright "don't do x" - then we can either go to "now it's forbidden" or we realize the guidance goes against real use cases..
Manu Sporny: where the JWT stuff can be very explicit: do not do it. the base spec can say "this is what people are expecting" . see VC-JWT for more information on this.
Samuel Smith: echo Orie's statement. if I sign a receipt. if someone purchases from me, it's signed, it has a proof. I give a receipt on the proof that I sign, referencing what they sign. liability on issuing receipt is on me..
Gabe Cohen: The use case for tunnelling, at TBD, transport credentials over DWNs. Use cases on status list, different signature methods, blob might be signed as a VC itself, might have many different types -- tunnelling is real..
Michael Prorock: different between verifiable+credential and verifiable/credential.
Dave Longley: need to know what you care about a priori. need to decide what you're verifying and make decisions there. let's make sure we know where the knowledge is coming from. verifier should know ahead of time what it's looking for and willing to verify.
Orie Steele: queued to comment on verifiable+credential or verifiable-credential - have been comments on #1014. if the dash were changed to a plus it would say there's a direct relation to credential...only a content type when ld+json, different than verifiable-credential+otherstuff. what Ted said: verifiable-credential and credential are at the same level. Michael Prorock: just do this in 'vc-jwts': if this is a W3C....we eat this up in the browser. we need to think about what I, as a browser, see application/??? - do I know how to verify it?.
Manu Sporny: all vendors support application/ld+json. tell vendors do things as you've always been doing..
|
|
Open for 2 weeks, no objections, merging |
|
I see no conclusion in the discussion! This "open for 2 weeks, merging" declaration is capricious and has not been announced before becoming an action. I question whether "no objections" is accurate. This should not have been merged given the current state of discussion. |
|
@TallTed My read of this PR and the associated comments does not agree with your assertion that @OR13 was acting capriciously, nor that the PR should not have been merged. @mprorock suggested a change, @OR13 responded. You and @dlongley sought clarification, to which @OR13 responded. I see two comments (which were addressed) and two approvals, followed by two weeks without further comments, with no stated objections or requests for changes. I see no reason to reverse this PR. |
…dataflow policy engine: README: Add inital sketch Related: w3c/vc-jose-cose#51 Related: #1400 Related: #1315 Related: #476 Related: #349 Related: #382 Signed-off-by: John Andersen <[email protected]>
Preview | Diff