<div dir="ltr">Lot's of this thread has veered off into the hypothetical. I guess I need to understand from Mike if his proposal for vx.yz claims applies only to SIOP, which (for example) has no need for a user info endpoint, or more generally.  If we can just include the needs of siop in the siop doc, there will be less of this hypothetical to deal with.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 11:23 PM David Waite via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Apr 9, 2021, at 12:00 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Hi David,<span> </span></span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">1. Using JSON-LD as a way to pass RDF-defined attributes inside a JWT in an isolated manner. As an example, trying to (e.g.) define an @context for the root of the JWT payload to represent it as a VC or VC-adjacent RDF graph would put us in the same undesirable security posture as VCs with LD-Proofs are today - a single set of security-related data which can be interpreted in multiple ways by different tools. Those of us with XML battle scars know the sorts of ways implementers can mess this up, even _with_ properly declared security considerations. This was fixed in DIDs by having JSON and JSON-LD be considered separate formats.<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Would that be a reason to not include the JSON-LD payload in the id token (or whatever JWT comes to mind) at all?</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote><div><br></div><div>Just to be clear, there may be different things happening with different trade-offs.</div><div>1. JWS with a payload of JSON-LD information</div><div>2. JWS with a JSON-LD -based VC / VP payload</div><div>3. JWT as defined by the VC data model spec (to have VC/VP data model encoded into a JWT)</div><div>4. JSON-LD content embedded as a claim in an id_token/userinfo response</div><div>5. VC/VP content embedded as a claim in an id_token, e.g. encoded to support both the VC and id_token rules.</div><div><br></div><div>(#1, #2 and #4 don’t appear to exist yet - I’m not sure if that is because JSON-LD interest is being driven entirely by the identity use case or if it is for some other reason)</div><div><br></div><div>I would be fine personally separating out VC/VP data from the id_token. In a way, it is somewhat surprising that there was never an inline userinfo_token for claims (I admit to not fully understanding the body of trade-offs there, though)</div><div><br></div><div>Embedding JSON-LD in general - there are really two issues, overlapping namespaces between the JSON-LD context and the JWT, and potentially having two different understandings of the content depending on whether the JWT payload is being evaluated as JSON or as RDF. Both of these are solved by having the data embedded in a claim, vs having the attributes and an “@context” at the root.</div><div><br></div><div>Embedding VC information in a JWT per VC rules has a lot of impact, partly because the security properties are both under defined and open to interpretation.</div><div><br></div><div>For example, that spec allows you to either use a  JWS signing algorithm, or use a “proof” element in the VC with the JWT being set to alg “none”. You must also transfer or duplicate values like the credential subject @id to `sub`. However, there are a many security-impacting edge cases here, for example:</div><div>- having values which are only present in the JWT claims when you have disabled signing means they may not be covered by a signature</div><div>- <span style="color:rgb(0,0,0)">removing the id from credential subject changes the interpretation of the RDF</span></div><div><span style="color:rgb(0,0,0)">-</span><span style="color:rgb(0,0,0)"> </span>altering the RDF by transferring values over will affect the canonicalization, and thus the signature</div><div>- if the value exists in both places, there is no rule for processing e.g “<a href="http://credentialSubject.id" target="_blank">credentialSubject.id</a> and `sub`, if both exist, must both be set to the same value” and “if <a href="http://credentialSubject.id" target="_blank">credentialSubject.id</a> exists and sub was not set, the JWT is considered invalid."</div><div><br></div><div><br></div></div><div><blockquote type="cite"><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br>2. Using a JWT as an envelop for LD-Proof signed JSON-LD data. This is appropriate for a verifiable presentation of say an RSA-based proof VC, where the presentation step is more about applying a proof-of-possession than doing any sort of manipulation (selective disclosure, ZKP proof)<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">I think the reason for supporting JSON-LD in this context is to allow for selective disclosure and ZKP proofs.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote><div><br></div><div>There are no semantics currently for a JWT to have selective disclosure semantics or to use ZKP proofs. So we can embed these in, as a JSON sub-document, a string, or base64 encoded data, to be consumed by those who can understand them.</div></div><div><blockquote type="cite"><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">So what is your concrete recommendation for treating JSON-LD based VCs/VPs? Embedding as JSON, separating them by base64url encoding, separating them in separate artefacts,…?</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote><div><br></div></div><div>Right now it would be for them to be separate artifacts. However I don’t know if I have the same set of use cases in mind that Mike does (in particular, he mentioned use cases where they are claims from the UserInfo Endpoint).</div><div><br></div><div><font color="#000000">I haven’t seen a proposal, but I suspect we will have issues with portable identifiers in SIOP use cases. When the portable identifier verification methods do not correspond to a JOSE signature algorithm, how do you protect an id_token?</font></div><div><br></div><div>-DW</div><div><blockquote type="cite"><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></blockquote></div></blockquote></div><br></div>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>