[ogsa-wg] [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007

[Nate Klingenstein]

Blair & Andrew,

I'm not sure the former -- having authorities describe what they're  
authoritative for -- is entirely desirable or practical.  When we  
discuss "authoritative for xyz data" in the context of identity  
information, I think it's necessary to append "for person abc" for it  
to have much meaning.  My IdP isn't your IdP, the same attribute may  
be expressed by multiple authorities, and my release policies are  
likely to vary by SP, so this appendix adds a great deal of  
complexity.  For each SP to manage and interpret the matrix of  
attributes/authorizations/identifiers and authorities for every  
principal they deal with strikes me as unreasonable and unnecessarily  
compromising of privacy.

This gets back to my core philosophy: the IdP should push everything  
it can, and for what it can't push(e.g. things it's not authoritative  
for), it should push the information needed to retrieve the  
additional attributes/authorizations, ideally via a discovery service  
associated with that user.  The discovery service can dynamically  
handle the user/authority/request pile and collect either raw data or  
pointers as appropriate.  If someday there's an intelligent client,  
then it can manage attribute and authorization locations for a  
principal internally, which is even better.

That said, I do think conversely there's value in SP's advertising  
the attributes or authorizations they need in order to reduce the  
need for callback queries, as those requirements are likely to be  
relatively static and unlikely to vary by IdP or user.

There are additional questions to consider when talking about  
attribute metadata, though.  Does some third party, e.g. a federation  
or a CA, need to vouch for my IdP's claim that it's able to assert  
staff at microsoft.com?  Will that third party be universally trusted by  
all the SP's I deal with?

The SP retains, and will always have, the right to validate and  
interpret information it receives.  I believe it's the job of the  
authorities, intermediaries, and flows to preserve as much of that  
information as is practical so the SP has the basis for a decision  
once the information arrives.  Whether the SP would like to rely on  
the certification of an external authority or its own judgment, it's  
able to do so.  Any standard should recognize both sides of this coin.

Anyway, regardless of your own beliefs, the expression of both  
attribute expression and request is possible today by using the  
<RequestedAttribute> and <saml:Attribute> elements from the SAML 2.0  
metadata profile.  Inasmuch as privileges and identifiers 
(NameIDFormat can be declared too, FWIW) can be thought of as  
attributes, I think this supports what you'd like to do, but not at  
the web services layer.  The Higgins project seems to be trying to do  
this using WSDL through the IdAS API, but I don't know enough about  
it to talk authoritatively.  ID-WSF and WS-Federation have somewhat  
coarse-grained abilities to express where attribute information is  
located as well.

Does this make any sense to you?
Nate.

On 8 Mar 2007, at 22:40, Blair Dillaway wrote:

> [blaird] I see two important aspects to this. First, authorities  
> need to be able to communicate what they are authoritative for  
> (attributes, types of principal identities, ...) so that resource  
> admins can know what they can rely upon in developing authZ  
> policies. Second, resources need to be able to communicate what  
> authenticated information they require (token types, which  
> authorities, ...). WS-SecureConversation (http://www.oasis-open.org/ 
> committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf)  
> could potentially be profiled as a way to do the latter. I'm not  
> aware of an existing std that addresses the former.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070308/0e05b0bf/attachment.html