eduPersonTargetedID and transcoder rules

[Wessel, Keith]

Well, duh. That makes perfect sense, and I should have known that. I was just thinking of decoding from the proxying perspective, but I should know from OIDC reverse mapping in the IdP that the requested attributes in metadata also require this reverse. So, yes, that makes perfect sense.

I'd say this warrants a note in the documentation somewhere, but I'm not sure exactly what or where. So, I'll try and think about that.

Thanks for the explanation, and sorry for the false alarm.

Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, April 5, 2022 6:22 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: eduPersonTargetedID and transcoder rules

On 4/5/22, 6:41 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    Attributes are being released by <RequestedAttributes> elements in 
> metadata and an attribute filter policy that releases any requested 
> attributes from metadata to any SP in this particular group. With decoder = false, I get no attribute released. Without decoder = false, I do.

That's what decoders do, they translate SAML to IdPAttribute. The RequestedAttributes syntax is SAML, it has to be converted into the internal form (at least as far as mapping naming) to identify which attributes to release.

If you set decoder = false, that short-circuits the knowledge it needs.

When you attach an AttributeEncoder the older way, that's implicitly a decoder and an encoder, it's a silly way of building the reverse mapping rules because until all that was replaced, it was the only way to do it.

Transcoding is normally bi-directional. The only real reason I added the ability for directionality was for proxying, in case you want to support a bogus mapping inbound without reflecting it outbound. So encoder = false would be the typical use case, not the other.

-- Scott