Shibboleth Developers

["Scott Cantor" <>]

> Comments/Questions:
> 
> - In section 3.2.2, what should be the value of the Resource attribute
> if the requesting entity is not a service provider?
>
> - In section 3.2.3, what should be the value of the <saml:Audience>
> element if the requesting entity is not a service provider?

That is not a Shibboleth profile, so it's N/A for this document, IMHO. We
can't address other SAML profiles in this document. It's a fact that we
screwed up, SAML screwed up, etc., but that's not fixable. We did what we
did, and our current profile is in stone.

So if somebody is using an alternate profile, how is that recognizable? I
think the answer is that it's either materially different messaging (a fixed
or absent Resource value, an XML extension, a header, etc.) or it's not, in
which case there is no way to run both profiles on one endpoint and the
endpoint would know what to do in each case. I believe that's more or less
how Walter has laid it out at this point.

> - In section 3.2.2, what are the requirements (if any) with respect to
> <saml:AttributeDesignator> elements?  Is there a specified
> relationship between the <saml:AttributeDesignator> elements and any
> <md:RequestedAttribute> elements listed in metadata?

Nope, none whatsoever and metadata NEVER takes precedence over actual
protocol which is why protocol bits are ALWAYS preferred. As a similar
example in 2.0, the NameIDFormat list in metadata has nothing to do with
what formats an SP could request in its AuthnRequest. It's advisory, to be
used if it's useful and not if it's not.

An AA could, at its discretion, examine metadata to decide value filtering
until we get to 2.0, I suppose. But all of that stuff has always been viewed
mostly as ARP fodder.

I will explicitly note that I don't think we're going to insist on using the
new extension for attribute requesters for the Shibboleth use case since
Shibboleth assumes SSO. But whatever we do someday with any attribute
metadata we will be sure to implement for both elements to accommodate other
profiles.

Specifically, I mean that I think the Shib profile AA endpoint will keep
using the SPSSODescriptor's KeyDescriptors for authentication in accordance
with the current documents.

-- Scott