GEANT OIDC plugin

Janne Lauros janne.lauros at csc.fi
Tue Sep 11 12:29:16 EDT 2018


>Yes, I'm aware they support affiliations, as do we, so that would just have to be factored back into the implementation in the same way the equivalent SAML feature already is, though I'm sure it's unused in OIDC just as it was in SAML. My concern is >just whether having a suffix is inherently a problem, and I don't believe it is.

 Currently we have the pairwise subject implemented by the book. It works as exactly as defined in the specification as for using sector_identifier_uri's and everything. As for public sub values, many deployments do want to use plain text sub values. I have not yet taken a look at how the new saml2 pairwise stuff works but I would be hesitant to loose these characteristics just to move from nameid generation to that. But as said, I have not taken that look yet.

 Br Janne 

----- Original Message -----
From: "Scott Cantor" <cantor.2 at osu.edu>
To: "dev" <dev at shibboleth.net>
Sent: Tuesday, 11 September, 2018 16:45:03
Subject: Re: GEANT OIDC plugin

On 9/11/18, 9:34 AM, "dev on behalf of Tom Scavo" <dev-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:

> That's an interesting idea. A sub claim value is any ASCII string
> (<=255 chars) so stuffing a scoped attribute in there is possible, I
> guess. The problem is that sub claim values are defined to be case
> sensitive.

We can generate case-safe values, and we do.
 
>- No allowance is made for stored IDs.

It has nothing to say about it any more than SAML does.

>- A computed ID depends on the client's Sector Identifier
> (sector_identifier_uri), which is a URL.

Yes, I'm aware they support affiliations, as do we, so that would just have to be factored back into the implementation in the same way the equivalent SAML feature already is, though I'm sure it's unused in OIDC just as it was in SAML. My concern is just whether having a suffix is inherently a problem, and I don't believe it is.

-- Scott


-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net


More information about the dev mailing list