Skip to content

Fix typos in JWT encoding decoding #711

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.

Sign up for GitHub

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

Closed
wants to merge 6 commits into from
Closed

Fix typos in JWT encoding decoding #711

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
e9919bb
Update index.html
David-Chadwick Aug 8, 2019
38a5773
Update index.html
David-Chadwick Aug 9, 2019
5463a8e
Update index.html
David-Chadwick Aug 12, 2019
8f0532e
Update index.html
David-Chadwick Aug 13, 2019
f2a5491
Update index.html
David-Chadwick Aug 14, 2019
2540dfb
Update index.html
David-Chadwick Aug 15, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 15 additions & 10 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3478,7 +3478,7 @@ <h5>JWT Encoding</h5>
<p>
If no explicit rule is specified, <a>properties</a> are encoded in the same way
as with a standard <a>verifiable credential</a>, and are added to the
<code>vc</code> <a>property</a> of the JWT. As with all JWTs, the JWS-based
<code>vc</code> <a>claim</a> of the JWT. As with all JWTs, the JWS-based
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes for property->claim are fine.

signature of a <a>verifiable credential</a> represented in the JWT syntax is
calculated against the literal JWT string value as presented across the wire,
before any decoding or transformation rules are applied. The following
Expand Down Expand Up @@ -3554,24 +3554,30 @@ <h5>JWT Encoding</h5>
in the <a>verifiable credential</a> <a>subject</a>.
</li>
<li>
<code>aud</code> MUST represent the <code>subject</code> <a>property</a> of the
consumer of the <a>verifiable presentation</a>.
<code>aud</code> MUST represent (i.e., identify) the intended audience
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change could be considered substantive, although I expect no implementations would change.

of the <a>verifiable presentation</a> (i.e., the Verifier(s) intended by
the Presenter to receive and verify the <a>verifiable presentation</a>).
</li>
</ul>

<p>
Other JOSE header parameters and <a>claim</a> names not specified herein can be
used if their use is not explicitly discouraged. Additional <a>claims</a> MUST
be added to the <code>credentialSubject</code> <a>property</a> of the JWT.
</p>
Other JOSE header parameters and JWT <a>claim</a> names not specified herein can be
used if their use is not explicitly discouraged. Implementers MUST add claims about
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a normative change.

the <a>subject</a> to the <code>credentialSubject</code> property of the JWT
<code>vc</code> <a>claim</a>, and <a>properties</a> of the
<a>verifiable credential<a> to the <code>vc</code> <a>claim</a>. Such <a>claims</a>
about the <a>subject</a> and <a>properties</a> of the <a>verifiable credential<a>
MAY be echoed/repeated, but should not be placed solely in the JOSE header parameters
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is additional normative guidance, and I'm concerned that it'll lead to non-interoperable JWT implementations. It's basically saying "some implementations may echo/repeat JOSE header parameters or JWT claims... but others may not echo/repeat, or may not even echo/repeat the same things." That will inevitably lead to some implementations doing the opposite of what other implementations do. I suggest we don't change this as it doesn't clarify things and only further confuses the issue.

or JWT <a>claim</a> names not specified herein.
</p>

<p>
This version of the specification defines no JWT-specific encoding rules for
the concepts outlined in Section
<a href="#advanced-concepts">Advanced Concepts</a> (for example,
<code>refreshService</code>, <code>termsOfUse</code>, and
<code>evidence</code>). These concepts can be encoded as they are without any
transformation, and can be added to the <code>vc</code> <a>property</a> of the
transformation, and can be added to the <code>vc</code> <a>claim</a> of the
JWT.
</p>

Expand Down Expand Up @@ -3618,8 +3624,7 @@ <h5>JWT Decoding</h5>
<li>
If <code>exp</code> is present, the UNIX timestamp MUST be converted to an
[[!RFC3339]] <code>date-time</code>, and MUST be used to set the value
of the <code>expirationDate</code> <a>property</a> of
<code>credentialSubject</code> of the new JSON object.
of the <code>expirationDate</code> <a>property</a> of the new JSON object.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a normative change as it changes where the data goes.

</li>
<li>
If <code>iss</code> is present, the value MUST be used to set the
Expand Down