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

[Mischa Salle]

On Mon, Mar 01, 2021 at 10:39:12PM +0100, Davide Vaghetti wrote:
> 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

Hi Davide,

small addition to the notes.
Concerning the affiliation, I think the issue is not so much with the
verification and trust but on the agreement of the meaning of each
affiliation (which you only partially solve with a scope). But also that
point is a point for the R&S working group, and not for us.

Cheers
Mischa

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



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


-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3402 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20210302/0a130ded/attachment-0001.bin>