RequestedAttributes and EntityAttributes

[Rod Widdowson]

> >I'll need to regroup and take stock and the report back (I have a minor
> >niggle about what we do about isRequired in the case where we are an
> >Attribute not a RequestedAttribute, but that will sort itself out)
> 
> I think it will probably just need to be carried into the ObjectMetadata,
> so the objects we put there are probably of a type that will have a
> subtype that carries the flag, mirroring the Attribute/RequestedAttribute
> relationship.

That’s easy enough.  The EntityAttributes will be Object Metadata for the
Entity and RequestedAttributes will be for the ACS.
Further SAML RequiredAttributes turn into (IdP) RequiredAttributes and SAML
Attributes [will] turn in to (IdP) Attributes.
A small change to the current filter will finesse the rest.

Indeed my question was about processing isRequired and onlyIfRequired
(because I hadn't read the code closely enough), I now see that without the
one the second becomes irrelevant.
 
> Oh, I would say that AttributeInMetadata we reserve to mean "from the
> RequestedAttributes in an ACS", and define something else for the
> EntityAttributes case (which I think we already did?).

Not that I remember.  But I hope someone will correct me.  For now I'll got
for "EntityAttributeInMetadata".
 
> As for queries, I would not implement that in the filter engine. It may be
> simpler to code there because of duplication, but I don't think it belongs
> there, I'd rather do it explicitly in an Action inside the query flows.

Absolutely.  As I recall the attribute resolver has a place to plug in
'requested attributes names', so that becomes really simple and has no
filtering except for when the AttributeQuery contains AttributeValues.  To
handle values we 'just' need to make that 'requested attributes' and at the
iterator you refer to at the end (after resolution has completed).  Actually
ss I type that, a better solution would be to do that completely separately
from the resolution.  So "resolution" Action takes requested attribute names
and produces attribute and the "time atttibute values" Action takes resolved
attributes and requested attributes and applies the trimming. I've made up
the word trimming here to distinguish from filtering.

I've entered case 418 for this flow.