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

[Niels van Dijk]

Hi,

On 15-02-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.
+1
> 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. 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.

Simply because of the fact that we do not control all software products 
already out there in use within our community (like various MS 
products), this is a no go I'd say.

Niels

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20210215/364fd461/attachment.html>