shibboleth-dev - RE: FINAL CALL -- Shibboleth Protocol Specification
Subject: Shibboleth Developers
List archive
- 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
- FINAL CALL -- Shibboleth Protocol Specification, Steven_Carmody, 08/19/2005
- Re: FINAL CALL -- Shibboleth Protocol Specification, Ian Young, 08/22/2005
- RE: FINAL CALL -- Shibboleth Protocol Specification, Scott Cantor, 08/22/2005
- Re: FINAL CALL -- Shibboleth Protocol Specification, Ian Young, 08/22/2005
Archive powered by MHonArc 2.6.16.