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

[Mischa Salle]

Hi Paul.

On Fri, Mar 29, 2019 at 10:09:08AM +0100, Paul Millar wrote:
> I've just joined this group.

Welcome!!

> There's certainly a number of familiar faces here.
(-;

> On 28/03/2019 13:13, Mischa Salle wrote:
> > On Thu, Mar 28, 2019 at 12:39:42PM +0100, Roland Hedberg wrote:
> > > > I was wondering about the sub + '!' + iss suggestion.
> > > > 
> > > > I often found this notion: sub + '@' + iss. It seems logical to me to use
> > > > it like user at host, just like ssh or email.
> > > > 
> > > > Wondering whether the '@' was discussed. >>
> > > Looks too much like an email address. We wanted something that looked like nothing else.
> > > With the hope that people would not have any preconceived notion about what they could
> > > use them for.
> 
> FWIW, in dCache the SciToken (which is basically just a profile of OAuth2)
> identifiers are currently stored with a ':' separator (rather than '!').  To
> me, this looks like the iss is scoping the sub ("foo:bar" => "foo" is the
> scope within which "bar" is defined).
> 
> The other twist is that each SciToken issuer has a unique nickname within
> the dCache configuration.  So, rather than referring to an OP as
> "https://issuer 1.example.org/foo", the nickname might be "FOO".
> 
> The combined identifier would be "FOO:<sub>".
> 
> Identifiers for dCache's OIDC support are currently just <sub> (yeah, need
> to fix that.)
> 
> If you want to have an identifier from directly composing <sub> and <iss>
> then I guess one requirement is that it should be possible to decompose the
> token back to <sub> and <iss> in an unambiguous fashion.
> 
> <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


> [...] 
> > 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).

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

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

    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/764a0681/attachment.bin>