OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: more metadata questions...

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


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]