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

[Mischa Salle]

Hi Paul,

On Mon, Apr 01, 2019 at 01:18:01PM +0200, Paul Millar wrote:
> 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.
Yes, that seems to match
https://tools.ietf.org/html/rfc7519#section-4.1.1 and
https://tools.ietf.org/html/rfc7519#section-2

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

> > > [...]
> > > > 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.
But in any case both will be pretty much just String, even when
expressing a URI or URL, following
https://tools.ietf.org/html/rfc7519#section-2
?

> 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.
I agree that a JSON Object would be cleaner, it would be a tradeoff for
size versus 'beauty'...

> > >    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).
It's true that you could have those, but you would equally have them in
the id tokens, meaning it's not such a good idea. Although allowed,
there is no need to put complicated, i18n or UTF-8 in the sub. It's
mostly something like a long (hexa)decimal number. The sub claim is to
identify the user, but not really to present to the end-user.

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

But the good thing would be that you would see the *exact* same values
as you also see in the tokens/userinfo etc.! There is *no* translation
needed to go from the ID token, access token JWT, userinfo response,
etc. to get the unique identifier. No need to specify which type of
escaping, urlencoding etc is done...

> > >    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?
I agree that a JSON Object would have my preference, but depends on size
limitations...

> 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.
But they are not relevant to uniquely identify the user. For that you
need the combination sub, iss. So the question was, how do you combine
the sub and iss in a reliable way and I'd say a sub-JWT (there probably is
a word for that).

    Cheers,
    Mischa
-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4521 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190401/716887b0/attachment.bin>