Skip to Content.
Sympa Menu

shibboleth-dev - RE: FINAL CALL -- Shibboleth Protocol Specification

Subject: Shibboleth Developers

List archive

RE: FINAL CALL -- Shibboleth Protocol Specification


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Cc: "'Ian Young'" <>
  • Subject: RE: FINAL CALL -- Shibboleth Protocol Specification
  • Date: Mon, 22 Aug 2005 19:16:39 -0400
  • Organization: The Ohio State University

Thanks Ian...

> Line 254, "rely" probably should be "relying".

Yup.

> Line 173 and line line 238 say that use of an "https" URL as a
> providerId "may be advantageous for metadata publication" but don't call
> out the reason. I'm assuming that the reason that would be the case (as
> opposed to just using "http" URLs) is that it allows for the relying
> party to be identified and different metadata to be returned for
> different relying parties (round line 655). If so, it might be worth
> saying this explicitly somewhere.

It also considers the possibility that the SSL certificate is used to
authenticate and integrity protect the metadata. It presumes metadata is
self-asserted and trusted based on a rudimentary PKI, rather than centrally
distributed.

I'll try and add something, but metadata exchange is in its infancy. The
real reason is "just in case" and "https is better than http and you have to
do https anyway or SAML is a waste of your time".

> Section 3.3, and line 715 et seq: although there is a recommendation
> that transient identifiers generated by IdPs are not reused, there isn't
> as far as I can tell any statement either way as to whether a transient
> identifier can only be used by the SP to which it is issued. Does
> anyone care?

There are no profiles in scope of this document that involve more than two
parties, so it hasn't come up, but it's probably worth saying something. I
don't think the current code is even doing the right thing.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page