Shibboleth Developers

[Nate Klingenstein <>]

> > This cuts right to one of the broadest questions I faced when I wrote
> > this: is it a web browser TLS profile, or is it a more generic  
> > profile
> > that could be used by other types of clients?  I narrowed it down to
> > avoid scope creep and to stay targeted.  Do you think this was the
> > right decision?
>
> Just to add a little fuel to the fire, this was my first reaction as
> well, but as I read on, it became clear that you were addressing the
> browser use case only, so I didn't bother raising the issue.

I spent some more time thinking about this.  The most browser-specific  
things, really, are the set of bindings specified in the profile and  
the mention of cookies to persist sessions.  SAML can be bound to  
protocols other than HTTP, e.g. SIP, but I don't know if these  
bindings have been standardized or implemented.  They're definitely  
not the primary use case.  On top of vanilla HTTP, there's SOAP, for  
which there might already be options for this sort of integration of  
transit-layer security using SOAP with WS-Trust and ID-WSF.  I'm not  
sure.

There isn't much interaction with the binding anyway, so in a sense  
that doesn't really matter.  The primary reasons for constraint would  
be interoperability and straightforwardness.

I might take a stab at reworking this to be independent of the  
application layer protocol just to see if I run into other issues, or  
if it's too broad.  If you have any other compelling reasons or  
showstoppers, you could save me some time.

> I don't believe this profile applies in the case of a short-lived
> certificate (at least, I didn't see how it could be used).  Thinking
> out loud, wouldn't it be great if the IdP had a built-in CA that could
> issue short-lived certificates on-the-fly? <hint>

Taking the hint and raising you one, the 2.0 IdP is quite easy to  
extend for contributors. ;D

> > Would you keep them in there?
>
> No, and just a heads up, I'll be quick to point out this flaw in the
> SSTC.  I don't see the value of being redundant; indeed, there's
> negative value, to be sure.

I can't come up with a good reason to leave them in when I can just  
discuss compatibility discretely in 2.8.  The processing rules for  
bearer confirmation will be gone in the next draft.

> Discovery is optional, so I still think "SHOULD" is too strong.

Fair enough.  I'd like to leave something in, so I'll downgrade it  
to:  "MAY be used if the correct identity provider cannot be  
determined through inspection of the certificate."

Take care,
Nate.