[openid-specs-rande] Fwd: R&Sv2 discussion / OIDC (from Mischa Salle)

[Marcus Hardt]

On 15. Feb 2021 11:00, Davide Vaghetti wrote:
> Hi,
> 
> 
> On 15/02/21 09:17, Mischa Salle wrote:
> > Hi Marcus, Davide, all,
> > 
> > On Mon, Feb 15, 2021 at 09:01:28AM +0100, Marcus Hardt wrote:
> >> On 12. Feb 2021 18:28, Davide Vaghetti wrote:
> >>> I've given just a quick look at the current discussion. What I found it
> >>> really hard to understand is how the R&Sv2 EC could be used to "fix" all
> >>> that's (supposedly) wrong in OIDC core --- read that the sub is not
> >>> globally unique per se, but MUST be combined with the iss.
> >>
> >> I think there is a certain frustration in the discussion, because
> >> SAML-fans are very unpleased with the need to generate sub at iss. And there
> >> are pitfalls, that might need to be addressed. (e.g. whether to
> >> `lstrip('https://')` or if `urlencode(sub|iss)` make sense).
> > 
> > but why would you need to combine them into one? Why not just keep the
> > tuple {sub,iss} ? I think the idea that we need to have a single
> > attribute is itself SAML-inspired (although convenient).
> > If you want to know if claim-set A and claim-set B belong to the same
> > subject, you compare the iss and the sub independently?
> > I agree that there are many pitfalls once you start messing around with
> > the values. If we think there is an (additional) need for a single
> > globally unique identifier, it's probably better to add it
> > independently, e.g. as subject-id or eduperson_unique_id.
> > 
> 
> I agree with Mischa here, I think creating yet-another-weird-identifier
> out of the sub and the iss is not exactly the best option. I think we
> also need to make clear one important aspect: the whole discussion is
> tightly coupled with the use of Shibboleth as an OP, which means that in
> that OIDC implementation OIDC sub automatically equals to SAML
> subject-id.

There I see a potential clash: subject-id as the form of 

<sub> := <unique_id> "@" <sope>

OTHOH, I think there is the idea of

<eduperson_unqiue_id> := <sub> "@" <iss>, 

potentially ending up with 

<eduperson_unique_id> = <unique_id> "@" <scope> "@" <iss>

This has the potential of becoming very painful, but might be mitigated
with conventions. 

(Just to clarify what I wrote before)

> Now, I do not personally have any trouble with that, unless
> we want to make this the standard for ALL the OP out there wanting to
> work with R&S RPs.
> 
> 
> >> Discussing them in rande, and suggesting something coherent for R&Cv2 is
> >> probably a good idea.
> > 
> 
> +1
> 
> Davide
> 
> > Yep, fully agree!
> > 
> > Mischa
> > 
> 
> -- 
> Davide Vaghetti
> Consortium GARR
> Tel: +390502213158
> Mobile: +393357779542
> Skype: daserzw
> 



> -- 
> openid-specs-rande mailing list
> openid-specs-rande at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-rande


-- 
Marcus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4805 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20210215/f7a1463b/attachment.p7s>