Re: comments: draft-mace-shibboleth-arch-protocols-03

[Tom Scavo <trscavo@gmail.com>]

On Fri, 12 Nov 2004 15:52:08 -0500, Scott Cantor <cantor.2@osu.edu> wrote:
> > At first glance, that seems a bit premature.  By lumping the
> > AssertionConsumerService and the AttributeConsumingService together
> > underneath SPSSODescriptor, attributes of the latter apply to both
> > services equally.  For example, if WantAssertionsSigned is true, then
> > both authn assertions and attribute assertions will be signed, but I
> > can imagine wanting authn assertions (via browser/post) signed and
> > attribute assertions (via SOAP) unsigned.
> 
> Nobody even understands what the signing flags are for, and I regret in
> hindsight even adding them. They're not sufficient anyway. I tried to
> convince Rob to let me leave the AttributeConsumingService flag in, and he
> argued correctly that we'd need precedence rules, and what if you include
> only one assertion with both statements, etc.

Since attributes may be included with authn assertions, it is a good
idea to allow <md:AttributeConsumingService> elements inside the
<md:SPSSODescriptor> element, but attributes may be requested
separately so it also makes sense to keep
<md:AttributeConsumerDescriptor> as is.  This satisfies the needs of
an SP that requires the services of an AA only.

I don't see why precedence rules are required if the
<md:AttributeConsumingService> element is allowed in both places.  Am
I missing something?

> The rest of that metadata was always about SSO, not about queries. If you
> make a query, you don't really have to make the AA guess what attributes to
> send, you just tell it. 

Yes, but if the required attributes are in metadata, the SP doesn't
have to spell it out every time it makes a SOAP request.  Granted the
<md:AttributeConsumerDescriptor> is the least useful of all
descriptors (since it has no Location) but there must be some residual
value of including this element in metadata.

> So this was never about the SOAP use case, even if I
> was stretching it to cover that for my purposes.

I think by simply adding the <md:AttributeConsumingService> element to
the <md:SPSSODescriptor> element, you can have your cake and eat it
too.

Cheers,
Tom Scavo