-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add comments on key discovery #111
Conversation
index.html
Outdated
If <code>iss</code> is present in the <a data-cite="RFC7519#section-4.1.1">JWT Claims </a>, | ||
a <a data-cite="VC-DATA-MODEL#dfn-verifier">verifier</a> can use this parameter | ||
to obtain a <a data-cite="RFC7517#section-4">JSON Web Key</a> to use in the | ||
<a data-cite="VC-DATA-MODEL#dfn-verify">verification</a> process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean in the payload? Like if iss
were to appear in the Verifiable Credential expressed as application/vc+ld+json
? Or does it mean if iss
appears alongside a vc
claim in the 1.1 style?
I would think we'd want to avoid both cases in 2.0 and require these things to be in the protected header to keep layers separate for this external securing mechanism. Wouldn't getting key information from something in the payload also be incompatible with many existing JWT libraries?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think we'd want to avoid both cases in 2.0 and require these things to be in the protected header to keep layers separate for this external securing mechanism.
avoid both cases would mean banning the json member iss
from application/vc+ld+json
right?
I don't think that would get consensus... we tried similar things with proof
... which is still both allowed to be present or optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a clear (and I think, agreed upon) way to do the security in this particular case, right? We want people to move on from the VC JWT 1.1 stuff and get a clean separation? If so, it seems we might have consensus here to clearly direct people not to put iss
directly into the Verifiable Credential, but instead, if they are going to use it, put it in the protected header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a clear (and I think, agreed upon) way to do the security in this particular case, right?
Yes, I think so, the authority is IETF for terms registered with IANA that are from IETF RFCs... They define this behavior we profile on top of it.
We want people to move on from the VC JWT 1.1 stuff and get a clean separation?
Yes, we made typ
and cty
values that solved this.
If so, it seems we might have consensus here to clearly direct people not to put iss directly into the Verifiable Credential, but instead, if they are going to use it, put it in the protected header.
Disagree, we are not going to constrain the open world model... people WILL put iss
wherever they are allowed to (which is everywhere)... We have to explain what doing that means (document existing usage).
We won't get consensus to "ban terms in specific places", so it will happen in the payload and the header.
By default it should be interpreted by the security conventions from the relevant RFCs, that is what this PR does. That is why the language just mirrors the RFCs, and doesn't constrain further.
This PR does not change anything an implementer can do today, it acknowledges that there are thing they can do that have special meaning today (registered names in header and claimset), and reminds them to be aware of how those terms are used today.
index.html
Outdated
to obtain a <a data-cite="RFC7517#section-4">JSON Web Key</a> to use in the | ||
<a data-cite="VC-DATA-MODEL#dfn-verify">verification</a> process. | ||
</p> | ||
If <code>kid</code> is also present, it is expected to be useful to distinguish the specific key used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean kid
could be in the payload? It's defined as a header parameter:
https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.4
Or is this just referring to kid
appearing in the header and iss
in the payload? How should "also present" be interpreted here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, how is kid
to be useful to distinguish the specific key used
? This cries out for an example, or a fair amount of additional prose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, kid
is legal in payload, in the same way that baz
or alg
is legal in payload.
The sentence is not attempting to be specific about where kid
can be found, but kid
does have special meaning when its in the protected header.
can you make a concrete change suggestion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I've made a suggestion to clarify that we're talking about kid
being present in the protected header.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bunch of typical cleanup, and a few questions to be answered.
index.html
Outdated
to obtain a <a data-cite="RFC7517#section-4">JSON Web Key</a> to use in the | ||
<a data-cite="VC-DATA-MODEL#dfn-verify">verification</a> process. | ||
</p> | ||
If <code>kid</code> is also present, it is expected to be useful to distinguish the specific key used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, how is kid
to be useful to distinguish the specific key used
? This cries out for an example, or a fair amount of additional prose.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
@TallTed thank you for the suggestions, your text was much better. I have merged all except for this one: #111 (comment) I am dreading the conflict resolution for this, so I want to get all your changes merged into the branch before I attempt to resolve that, since I might have an easier time just lifting the section into a new PR. |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
This is good for this go-round. I don't have a suggestion on |
I've created #117 for this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me.
Co-authored-by: Dave Longley <[email protected]>
Co-authored-by: Dave Longley <[email protected]>
Co-authored-by: Mike Prorock <[email protected]>
@TallTed I think I have your suggestions, let me know if I missed anything. @dlongley I applied most of your suggestions, but this one is outstanding: #111 (comment) Is the issue marker I proposed acceptable? I'm trying to resolve all suggestions before addressing the merge conflicts, because I am bad at git. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving -- I've left a comment here: https://github.com/w3c/vc-jwt/pull/111/files#r1248318896. Thanks!
Ok, I think I am ready to tackle the merge conflict, wish me luck. |
@mprorock I believe all feedback has been addressed, and issue markers have been filed, I suggest we merge this. |
Preview | Diff