more metadata questions...

We’ve had some additional metadata questions raised by
the team here.

 

 
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?  

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

 
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?

 
When we have a relying party
     that is allowed to make general attribute queries to an attribute
     authority, we cannot see any way to support “general” queries
     and also be able to state that we want the attribute authority to sign the
     assertions.  The problem is that the <AttributeConsumingService>
     is where the WantAssertionsSigned attribute is defined, but the
     <RequestedAttribute> element under that element is defined as [One
     or More]. The assumption is that this is used to indicate that a consumer is
     interested in specific attributes or possibly specific values of specific
     attributes. However, for my more general attribute consumer, I don’t
     want to or can’t specify all attributes I’m interested in. I
     want a “wildcard” attribute, 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).

Rob Philpott

Senior Consulting Engineer 

RSA Security Inc. 

Tel: 781-515-7115 

Mobile: 617-510-0893 

Fax: 781-515-7020 

mailto: