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

["Philpott, Robert" <rphilpott@rsasecurity.com>]

> > 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.

[RSP] I agree it's an authority role.  But are you saying that to do
this type of retrieval, you'd use the service defined in the
<AuthnAuthorityDescriptor>?  My point is that Web SSO assertions are
often not the same as assertions that an Authentication Authority would
create. They might contain both authn statements AND attribute
statements.  So a web SSO "authority" is really a different type of
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.

[RSP] I'm okay with it as long as I can retrieve assertions by ID for
any type of authority role I may define.


> > 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.

[RSP] I agree it's mainly a schema issue and don't feel that strongly
about it.  The main point was to point out the inability IMO to retrieve
Web SSO assertions by their ID since they aren't the same as
authentication assertions.


> 
> > 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.

[RSP] Hmmm. I didn't interpret it this way (i.e. intended for the SSO
case) since a) it seems to have symmetry with the Attribute Authority
role, which in our product is specifically for general attribute
queries, and b) the WantAssertionSigned attribute in the
<AttributeConsumingService> could conflict with the WantAssertionSigned
attribute in the SPSSODescriptor.  

In our environment, I need to be able to describe whether to sign
attribute assertions that I send back in response to general attribute
queries. This is what I thought the <AttributeConsumingService> would be
used for. It's less important to us to have an SP define via metadata
what attributes it "might" query.  In most cases it might seem odd,
although it might be useful under certain conditions.  

Certainly for Web SSO, we need to be able to have an SP tell us what
attributes they need our IDP to include in the Web SSO assertions we
send them (I can't do it in the AuthnRequest and probably wouldn't want
to do it there anyway).  But this is distinct from the general attribute
query settings.


> 
> 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.

[RSP] I understand.  But do you see why we actually need settings for
general query support that are distinct from settings for SSO?


> 
> > 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. ;-)

[RSP] True enough.  In my opinion, we should put an SP's desired Web SSO
attributes in the SPSSODescriptor role definition and make the
<AttributeConsumingService> describe settings that a relying party needs
when it makes general attribute queries.