We consider implementing an intercept flow that adds another attribute
to the existing set of attributes (i.e. after the regular attribute resolution
took place). The source values for this attribute aren't known before the execution
of this intercept flow.
As far as I know, the IdP's regular attribute resolution stores the resolved attributes
to the context "ProfileRequestContext -> RelyingPartyContext -> AttributeContext".
Is the context "ProfileRequestContext -> RelyingPartyContext -> AttributeContext"
considered part of the API? Can we safely add attributes there?
I'm aware that we would need to take care of filtering ourselves.
(BTW, this relates to Etienne's thread "Building a composite attribute from sets of attributes".)
To unsubscribe from this list send an email to [hidden email]
Where you could run into bugs is if something unusual were created that we didn't handle correctly. I wrote the new Transcoder logic to be as defensive about values as possible, but it's conceivable there could be assumptions about not having IdPAttributes with no values or that sort of thing in the old code.
> I'm aware that we would need to take care of filtering ourselves.
Yes, though I'm going to add a quick/dirty way to run filtering like I did with the resolver earlier.