Skip to Content.
Sympa Menu

shibboleth-dev - Re: Draft Holder-of-Key Web SSO Profile

Subject: Shibboleth Developers

List archive

Re: Draft Holder-of-Key Web SSO Profile


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: Draft Holder-of-Key Web SSO Profile
  • Date: Fri, 15 Feb 2008 17:39:05 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WsS9D7Yo94usU/+0fA4dlZAS3J8b+ObWVXFyTUrj/6XvvPswFVTQSC5EhKSnI4jM2h7av9EL1xJ2I2rjBGzmjV2dzFkVMzW3nO3zNwVEDfUx2Siyo3vLNOOeTXYLa+UtHAIq5uk2jesbm8z2+in0z/O1CK7RC0BjMMEP4kdfGEg=

Well written, Nate. I don't personally think client certs in browsers
are very workable, but there are lots of good ideas in your profile.

From 1000 feet:

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

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

From 100 feet:

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

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

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

From 10 feet:

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

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

Cheers,
Tom

On Thu, Feb 14, 2008 at 9:18 PM, Nate Klingenstein
<>
wrote:
> Shibboleth-Developers,
>
> As part of my work for the National Institute of Informatics and the
> UPKI initiative, I've been working on a modified Web Browser SSO
> profile for SAML 2.0 that uses holder-of-key confirmation for the
> client rather than bearer authentication. The keys for this
> confirmation are supplied through TLS using client certificates. This
> results in a more secure sign-on process and, particularly, a more
> secure resulting session at the SP, and no need for the SP to do PKIX
> or know anything about the client certificate itself.
>
> As there has been some discussion about client TLS authentication to
> IdP's on this list, along with a bunch of sharp resident federated
> thinkers, I wanted to run the draft by you for any feedback or ideas
> before I take it to the SSTC for further work. All ideas or
> complaints, no matter how nebulous, are useful.
>
> I've attached it in PDF format. If you prefer another format, please
> let me know.
>
> Thanks for your (volunteered) time,
> Nate.
>
>
>
>
>



Archive powered by MHonArc 2.6.16.

Top of Page