Skip to content
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

Merged
merged 17 commits into from
Jul 5, 2023
Merged

Add comments on key discovery #111

merged 17 commits into from
Jul 5, 2023

Conversation

OR13
Copy link
Contributor

@OR13 OR13 commented Jun 26, 2023

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated
Comment on lines 372 to 375
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.
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@OR13 OR13 Jun 30, 2023

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.
Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor Author

@OR13 OR13 Jun 29, 2023

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?

Copy link
Contributor

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]>
Copy link
Member

@TallTed TallTed left a 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 Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
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.
Copy link
Member

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.

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
OR13 and others added 7 commits June 29, 2023 15:43
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]>
@OR13
Copy link
Contributor Author

OR13 commented Jun 29, 2023

@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]>
@OR13
Copy link
Contributor Author

OR13 commented Jun 29, 2023

@TallTed I have accepted all your changes, before I attempt to resolve merge conflicts.

@dlongley @TallTed do you have any more suggestions?

Regarding your comment on kid, I can't do much more on that front given the RFCs don't do much more, but I am happy to review suggestions if you have any.

@TallTed
Copy link
Member

TallTed commented Jun 29, 2023

This is good for this go-round. I don't have a suggestion on kid, so I suggest creating a fresh issue about that need, fixing this PR's conflicts, and merging this PR. Someone else may then come up with a suggestion on kid.

@OR13
Copy link
Contributor Author

OR13 commented Jun 30, 2023

@TallTed

There are a lot of open issues related to kid

Most of them have some relationship to your question, here is an example:

#31

Are you asking for an issue marker?

Or is it ok to just use the issue above?

@TallTed
Copy link
Member

TallTed commented Jun 30, 2023

I've created #117 for this.

index.html Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
@mprorock
Copy link
Contributor

@TallTed

There are a lot of open issues related to kid

Most of them have some relationship to your question, here is an example:

#31

Are you asking for an issue marker?

Or is it ok to just use the issue above?

i think referencing issue #31 works for me

index.html Show resolved Hide resolved
Copy link
Collaborator

@selfissued selfissued left a 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]>
OR13 and others added 2 commits June 30, 2023 16:07
Co-authored-by: Dave Longley <[email protected]>
Co-authored-by: Mike Prorock <[email protected]>
@OR13
Copy link
Contributor Author

OR13 commented Jun 30, 2023

@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.

Copy link
Contributor

@dlongley dlongley left a 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!

@OR13
Copy link
Contributor Author

OR13 commented Jun 30, 2023

Ok, I think I am ready to tackle the merge conflict, wish me luck.

@OR13
Copy link
Contributor Author

OR13 commented Jul 5, 2023

@mprorock I believe all feedback has been addressed, and issue markers have been filed, I suggest we merge this.

@mprorock mprorock merged commit 57ce7e3 into main Jul 5, 2023
@OR13 OR13 deleted the feat/key-discovery branch July 7, 2023 22:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants