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:rphilpott@rsasecurity.com
|