[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: comments: draft-mace-shibboleth-arch-protocols-03
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]