Shibboleth Developers

[Tom Scavo <>]

On Mon, 27 Dec 2004 18:01:21 -0500, Scott Cantor 
<>
 wrote:
> 
> The issue is, I guess, whether we want to replace the old request protocol
> that was used as a placeholder up until now with a more complete request
> message derived from the SAMLv2 spec. The motivation (as I understood it)
> was to feature-enrich the 1.3 release to put it on more equal footing with
> existing Web-ISO's that people have deployed (e.g. A-Select, pubcookie, CAS,
> cosign, etc.)

I don't see how adding AuthnRequest support achieves this goal.

> @ID
> @Version (fixed at 2.0 if we profile the 2.0 message)
> @IssueInstant (replaces the Shib time parameter, somewhat)
> @Destination (location of Shib SSO Service, aka HS)

Not sure the latter is "obvious".  In advance of WAYF/IdP discovery,
this value is unknown.  Moreover, without signing, it seems to serve
no purpose.

> <Issuer> (replaces providerId parameter)
> <ds:Signature> (allows signing)
> 
> These are the bits we can support without much work:
> 
> @AssertionConsumerServiceIndex
> Or
> @AssertionConsumerServiceURL
> @ProtocolBinding
> (replaces the shire parameter with a richer metadata-aware set of
> attributes)
> @AttributeConsumingServiceIndex
> (sort of a win here, if we have the metadata to support it, we can start
> actually doing attribute push with a query by reference if we want to)
> <NameIDPolicy> (just lets you specify the kind of identifier you want back,
> but we probably need to discuss the AllowCreate flag and the notion of
> persistent IDs for the 1.3 release)

The point of AllowCreate is not clear (there are only two brief refs
in the SAML 2.0 spec).  If it is tied to persistent identifiers, then
the spec should spell this out.

> <Subject> (sanity check when refreshing a session, you can send the original
> subject element, when using something other than a handle anyway)
> 
> These are the bits we probably *want* to support if we actually do this,
> based on the reasoning, but none of them are particularly simple:
> 
> @ForceAuthn (so-called session reset flag)
> @IsPassive (used for silent probes for SSO)
> <RequestedAuthnContext> (this is the field that can control the
> quality/level/method of authn, but it's in terms of the AuthnContext concept
> from Liberty/SAMLv2)

I would say the latter is out of scope for a SAML 1.1 implementation. 
It requires too much from SAML 2.0, I think.

> These are the bits we might support if we think it's at all useful...
> 
> <Scoping> (primarily N/A, but it does have a feature for carrying a list of
> acceptable IdPs or a pointer to a list that might be interesting from a
> WAYF/discovery standpoint, and it's not that hard)
> 
> These are the bits we probably blow off (i.e. profile out):
> 
> @Consent (don't ask)
> @ProviderName (for richer clients, sort of)
> <Conditions> (eventually useful, but not worth much with SAML 1.1)
> <Extensions> (probably better to save this for 2.0, but I dunno)

Tom