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

[Paul Millar]

Hi Mischa,

I've just joined this group.

There's certainly a number of familiar faces here.

For those I don't me, I'm working on an open-source (file) storage 
software called: dCache.  dCache is deployed throughout the world, 
typically stores petabytes of scientific data, provides (close to) POSIX 
semantics (and full of cutting-edge features :-)

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.  Therefore one scheme would be:

	<iss> <URI-unsafe-character> <sub>.

since it is guaranteed that a valid URI will not contain any 
URI-unsafe-characters:

	" < > # % { } | \ ^ ~ [ ] `

Of these, the pipe symbol '|' is perhaps the most aesthetically 
appropriate, since it is symmetric:

      <iss> '|' <sub>

An alternative would be to use one of the brackets (<>, {} and []).  As 
a comparison, XML namespaces are written in square brackets by some java 
libraries.

For example:

   <d:dCache xmlns:d="http://dcache.org/2018/01/>

would be written as:

   "[http://dcache.org/2018/01]dCache"

In the OIDC case, this would be written as:

     [<iss>]<sub>


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

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

   3.	it risks "feature creep" where more metadata is injected
	into what is meant to be a simple identifier.

Anyway, just my 2c worth!

Cheers,
Paul.