[openid-specs-rande] Fwd: R&S2.0 and OIDC mappings (was Re: Next R&S 2.0 call: 9 February 2021)

[Davide Vaghetti]

Hello everyone,

I'm forwarding a message that Heather sent to the R&S mailing list to
propose to leave the OIDC mapping of the spec to this group.

Please also find Today's meeting notes on the repo:

 https://github.com/daserzw/oidc-edu-wg/blob/master/meeting_notes.md

Cheers,
Davide


-------- Forwarded Message --------
Subject: 	R&S2.0 and OIDC mappings (was Re: Next R&S 2.0 call: 9
February 2021)
Date: 	Mon, 1 Mar 2021 07:23:32 -0800
From: 	Heather Flanagan <hlf at sphericalcowconsulting.com>
Reply-To: 	Heather Flanagan <hlf at sphericalcowconsulting.com>
To: 	rands at lists.refeds.org <rands at lists.refeds.org>



Hello all,

I’ll bring this up on the call tomorrow (agenda and v/c info to be
posted shortly) but I’d also like to make sure people review the thread
on the OIDC mapping. After reading through this and sitting in on the
OIDF rande call today, I’d like to propose we remove the OIDC mapping
from the draft spec. The mapping is no where close to being standardized
or even commonly agreed upon. There is work happening to make that
happen, but that work doesn’t belong in the R&S working group. This spec
should be a consumer of that effort. 

A few years ago, REFEDS had an OIDC working group. That group closed in
favor of consolidating their efforts under
OIDF: https://openid.net/wg/rande/ <https://openid.net/wg/rande/>.
That’s probably the best place to continue the discussion on OIDC to
SAML mapping.

Heather Flanagan — Translator of Geek to Human
https://sphericalcowconsulting.com <https://sphericalcowconsulting.com>
On Feb 11, 2021, 11:02 AM -0800, Cantor, Scott <cantor.2 at osu.edu>, wrote:
> On 2/11/21, 1:28 PM, "Marcus Hardt" <rands-request at lists.refeds.org on
> behalf of hardt at kit.edu> wrote:
>
>> Sure, but splitting the world into one version of R&S for services that
>> come before a proxy and one version of it for services behind it, or even
>> creating just one version that accepts breaking the behaviour of existing
>> services behind the proxy is not going to drive the acceptance of the
>> document, is it?
>
> The same could be said of SAML, but we tolerate SAML being completely
> broken in virtually all cloud integrations while still trying to push
> "correct" behavior amongst ourselves.
>
>> Furthermore, any OIDC RP that complies to the OIDC and JWT specs will
>> have
>> to look at "sub" and "iss" unless it then only talks to R&Sv2 OPs.
>
> More accurate to say I think that any RP that wants to not be broken
> will have to, but yes, that's true. There is no way to test an RP for
> compliance to a requirement that they "look at 2 things" in their
> application logic.
>
>> But this comes with a benefit: with the separate iss implementations can
>> verify the iss claim to be identical to the actual OP they have an https
>> connection to.
>
> Well, issuer identity validation is quite distinct from evaluating
> claims. One is a protocol matter, one is about data. Trying to combine
> them is a very big mistake. In particular, issuer becomes a wholly
> technical construct for a system that relies on conflating identity
> and location, so you don't get to just pick the right issuer value, it
> has to match your technical deployment. That's why SAML entityIDs
> *don’t* work that way, it is what allows policy to be independent of
> technical deployment details.
>
>> The scope portion of the subject-id "resembles a DNS domain name".
>> This is
>> good as long as I ultimately trust that SP.
>
> IdP, you mean, but yes. It moves the evaluation to a different layer,
> and that's for a very good reason.
>
>> What I want to say is: from the right perspective, both standards are
>> broken in a way.
>
> Agree to disagree; my biases are not hidden.
>
> -- Scott
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4428 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20210301/e1d64909/attachment.p7s>