Shibboleth Developers

["Tom Scavo" <>]

On Feb 16, 2008 8:04 AM, Nate Klingenstein 
<>
 wrote:
>
> > 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?

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.

> > + 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."

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>

> > - 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?

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.

> > - 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.

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

Tom