RE: [security-services] more metadata questions...

["Scott Cantor" <cantor.2@osu.edu>]

> 1.	The <AuthnAuthorityDescriptor>, <PDPDescriptor>, and 
> <AttributeAuthorityDescriptor> elements all include an 
> <AssertionIDRequestService> so that relying parties can 
> request a specific assertion from them.  However, the 
> <IDPSSODescriptor> does not provide a means to retrieve a Web 
> SSO assertion by its assertion ID.  For completeness, 
> shouldn't this be included?  

Do we have such a use case? I consider such an IdP to be simply playing the
more traditional role of an authority.

> 2.	On a related note, is it really likely that folks will 
> want separate endpoints for retrieving assertions by their 
> ID's based on the type of assertion that is being requested? 

I would think it's possible, and duplication isn't exactly a problem anyway.
In fact, we specifically went with the "duplication is better than defaults
and overrides" model with things like SOAP endpoints.

> IMO, requesting an assertion by its ID is really independent 
> of the type of assertion it is. So why isn't the 
> <AssertionIDRequestService> element factored out to the 
> higher-level <RoleDescriptorType>?

How would that help? You'd still need a concrete role that somehow meant
"any authority" so you could place the element in it. Factoring it out to a
new type doesn't eliminate any duplication. To do that, you'd have to have a
literally distinct role element.

> Or if we want to restrict 
> it just to asserting parties, it could be in a new 
> higher-level type (e.g. an <AuthorityDescriptorType> or 
> <AssertingPartyType>).  This would permit the definition of 
> other types of authorities later on (Credential Collector?) 
> without having to duplicate this service element in all of them. 

That's a schema design issue, I suppose, but I don't think it matters that
much. I could add another super-type if people felt strongly about it.

> 3.	On the call, it was agreed that we need to specify in 
> the IDPSSODescriptor what saml:Attribute and attribute 
> profile elements are desired for use in the Web SSO 
> assertions.  This makes sense for having an IDP describe what 
> attributes it will send.  But what about being able to 
> describe what attributes an SP needs to receive?  Should 
> <RequestedAttribute> elements appear in the SPSSODescriptor?

That's what the attribute consumer element is for. These are functional
roles but they're not mutually exclusive. If an SP wants attributes, then
it's also an attribute consumer. In fact, if I'm making a traditional query,
I can tell the AA what I want directly, I don't need metadata to tell it.
This element is *mainly* for the SSO case.

I separated it to reinforce the functional distinctions the metadata is
trying to capture so that other use cases that also had attribute
requirements can reuse it. That was partly why I didn't add the attribute
stuff to the IdP role.

> I suppose. I believe the easiest way to deal with this would 
> be to change <RequestedAttribute> to be [Optional] instead of 
> [One or More].  Here, I could specify an 
> <AttributeConsumingService> element with the signing setting 
> the way I way and interpret the absence of any 
> <RequestedAttribute> elements to mean I'm interested in all 
> attributes (subject to the usual policy controls).

I can buy that, although these new capabilities in practice make it kind of
a weird idea to have a wildcard entry. Seems like if you can't tell the
responder what you want, he isn't going to know either. We used to say it
was out of band, but this is the out of band mechanism. ;-)

-- Scott