[openid-specs-rande] today's meeting notes

[Paul Millar]

Hi Mischa!

On 01/04/2019 11:11, Mischa Salle wrote:
[...]
>> <sub> is an opaque token, while (IIRC) <iss> is always going to be a URI.
> 
> For OIDC, yes it's a URL actually (not even a URI), on the other hand,
> the JWT RFC7519 underpinning most implementation using 'fat' access
> tokens, only says StringOrURI
> https://tools.ietf.org/html/rfc7519#section-4.1.1

Err, OK.  To check I've understood this correctly:

JWT allows the 'iss' claim to be a non-URI (e.g., "foo bar"), provided 
it doesn't have a colon.

For OIDC, 'iss' is a URL, so must be a valid URI.


>> [...]
>>> yesterday during our AARC meeting I wondered whether we can't just use a
>>> JSON (either as JSONObject with the claim names, or as JSONArray). It's
>>> not that much longer and clearly defined: by definition it must be
>>> expressible as such.
>>
>> While certainly an option, it seems an inelegant solution to me:
>>
>> 1.	it does make the identifier longer than necessary,
> I agree with that, although in particular a JSONArray would add a very
> minimal overhead (but requires slightly more parsing code and a clear
> definition of the order).

True, a JSON array likely adds only limited overhead.

The other (minor, almost stylistic) issue is that the JSON array would 
combine dissimilar items (an opaque string and a URL).  I believe JSON 
arrays are normally used to combine similar items.

It's almost like using a JSON array to create a "lite" JSON-object, 
where an item's index defines the semantics of the item.


>>    2.	certain characters would need to be escaped -- reading
>> 	the identifier becomes (in some cases) non-trivial

> No, that makes no sense: we're talking in any case about something that
> can be put into a JWT (either a OIDC ID token, or a OAuth2 using JWTs as
> access tokens) as sub/iss claims. You just put whatever is in that JWT
> 1-to-1 into the new JWT.

Perhaps this is off-topic, but here's the use-case I'm thinking of.

If the identifier is recorded somewhere (e.g., a log file) then there's 
a good change that it will be read by a human using 'less' (or equivalent).

So, I think it is a reasonable expectation that a human should be able 
to read the log file and decompose the identifier; for example, sending 
the 'sub' claim in an email to the security contact for the 
corresponding 'iss'.

If the 'sub' value contains either a double-quote (") or back-slash (\) 
then the value must contain these values escaped.  This is usually "\"" 
or "\\" (respectively) but the JSONString encoder could use Unicode 
values instead: "\u0022" and "\u005c" (respectively).

However, an encoder is free to encode other items that it believes might 
cause trouble.  IIRC, I've see JSON where '=' characters were escaped 
using their unicode equivalent.

This means the admin looking at the identifier may need to know JSON 
encoding in order to understand the logged identifier.

All of this is probably OK: people will probably guess that some kind of 
escaping is going on; however, it might be better to avoid such 
complications.


>>    3.	it risks "feature creep" where more metadata is injected
>> 	into what is meant to be a simple identifier.
> I would claim (no pun intended) the opposite: the natural representation
> is as claims in a JWT, so what's better than to use a 'reduced' JWT just
> containing those two claims?

That's a fair point .. although it shouldn't it then be a JSON Object?

My "feature creep" point was that, then somebody wants to record the 
'jti' claim (to know if a replay attack is taking place), and someone 
else wants to know the date claims ('iat' 'exp', 'nbf'), or perhaps the 
'aud' claim.  All are easy to add.  Before you know it, you have the 
entire JWT payload as the identifier.

Cheers,

Paul.