Contexts and attribute operations

[Rod Widdowson]

The attribute filter and attribute resolver code predates us finalizing our
use of contexts and so their use of contexts is pretty ad hoc.

It has become urgent that we document the use that these operations make of
contexts, but before doing this I’d like to find out what we think these
should look like.  Then I can make them look like that before I do the work
of documenting them.

Currently, both operations make use of three separate context types.  Two
(one for resolution, one for filtering) are used mostly as workspace, they
contain some parameterization, but they are also where work in progress and
final results go.  The other serves just as a bucket for extra
parameterization.   

The general idea was that the extra parameterization could be found by
walking the context tree, but when I wrote the code we didn’t know what that
would look like.

For the record the extra parameterization consists of:
	Strings (4): principal, attributeIssuerId,  attributeRequesterId and
principalAuthenticationMethod
	Metadata Fragments(4): EntityDescriptors and RoleDescriptor for
requester and issuer.


 and is made available to both the Attribute Resolver and the Attribute
Filter.

I’d like to revisit this and ask (and here I probably mean mostly Scott)
whether we think this is where we want to be.  As I see it we have three
options:

1)	Leave things as is, but make the navigation a little bit more
sensible
2)	Move all the parameterization into the workspace context (which
already contains some parameters after all)
3)	Add code to grab this information from the ProfileContext
[in]directly.  If all the information is always in the ProfileContext, that
might be fine, but I suspect that it isn't and hence I don't like this
option much since it does tie the resolution code to the precise context
relationships. 

/Rod