Shibboleth Developers

[Nate Klingenstein <>]

Wow, you guys are quick.  Thanks a lot for the support and ideas; this  
stuff is great.  I've consolidated my responses into a single email

Diego me escribió:

> I see it as a pretty interesting step towards a better integration  
> with our
> Grid communities, as well as a source of interesting ideas for the  
> profiles on
> automated network clients we are working with in eduGAIN.

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?

> + Don't you think that the use of Short-Lived Certificate Services  
> (see the SLCS
>  developed in EGEE-II: http://www.terena.org/activities/nrens-n-grids/workshop-06/slides/witzig-switch-slcs-vash.pdf) 
>  shall be discussed as a mitigation of the
>  cert being a persistent ID?

Yup, that would be exactly the kind of implementation needed.  I won't  
make specific reference to the project itself since this is a  
specification, but I tried to raise the SLCS concept by saying "unless  
a new keypair is issued for every transaction."

And Tom wrote:

> - I'll note that there seems to be many more references to bearer
> SubjectConfirmation than are actually necessary.  In section 2.5, in
> particular, there are ten references to "bearer" that essentially
> duplicate what is already covered in section 4.1.4 of [SAML2Prof].
> What is the purpose of that redundancy?

The goal was to retain those statements for compatibility with the  
standard web browser profile, as alluded to in 2.8.  It would require  
an endpoint for this profile to properly process and send bearer  
assertions so a standard browser SSO endpoint could talk to a holder- 
of-key browser SSO endpoint.

You might point out that they could just register a second endpoint in  
their metadata, and you'd be right.  I don't think the statements harm  
anything, but they could be dilutive.

Would you keep them in there?

> - I've heard that Microsoft severely broke client certs in IE7.  Do
> you know about that?

I know that they have a novel interpretation of "optional" that has  
already caused me a great deal of frustration.  There may be other  
problems that I'm unaware of, but I'm not sure I even want to know.

> - The profile would be easier to read if you qualified all SAML  
> elements.

Good point, particularly as some were samlp and others were saml.   
I'll add these early next week because it's going to take awhile.

> - The normative "SHOULD" on line 298 seems too strong.  I'm not sure
> what you're trying to accomplish with that sentence.

I don't impose any requirements on what should be in the certificate  
or how to do discovery based on its contents.  Certificates are  
already widely deployed, and they're intended to last a long time, so  
I'm wary of asking for any change there.  That implied a need for a  
backup discovery method in case there is no ability to do discovery  
based on the certificate and its fields.

> - There's something wrong with the wording on line 326.

Leftover "matches" from some rewording.

> - [line 3] s/Committee Draft/Working Draft/  (you must be trying to
> "fast track" this profile :)

That's a much better excuse than ignorance.  May I borrow it? :D

> - [line 200] s/this confirmation method/the  
> <saml:SubjectConfirmation> element/

Done.

These were great ideas, guys, thanks.  Would welcome more within the  
next week, as I intend to take it forward to the SSTC around the  
beginning of the following week.
Nate.