<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML DIR=ltr><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"></HEAD><BODY><DIV><FONT face='Arial' color=#000000 size=2>
<DIV><FONT face="Courier New" color=#000000 size=2>Hi</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>I propose the following
profiles as addition to OpenID auth </FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>spec. In the OpenID
spirit, I have tried to keep these <BR>profiles as simple to implement as
possible.</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>The idea here is to list
security-related variants in the spec <BR>and then specify a few profiles to
require certain subsets of <BR>these variants. The IDP and the RP may
publish compliance with <BR>profile(s) in their discovery
documents.</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>Note: the list of security
variants is not implicitly complete.</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>Some variants are enforceable
only via cooperation IDP/RP. This <BR>means there are sometimes no way in
the protocol to detect </FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>whether </FONT><FONT
face="Courier New" color=#000000 size=2>a party complies to that variant of a
profile. (For </FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>example, </FONT><FONT
face="Courier New" color=#000000 size=2>variant 5 listed below is of this
type.)</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>Also note that some variants
are identified because of possible <BR>future security
threats.</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000
size=2>Variants<BR>--------</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>Notes on the variants relate
to draft #9.</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>1. Wildcards allowed in
trust roots
one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New" color=#000000 size=2></FONT> </DIV>
<DIV><FONT face="Courier New" color=#000000 size=2>Whether the IDP accepts wild
carded trust roots as specified<BR>in section 8.2</FONT></DIV><FONT face=Arial
color=#000000 size=2>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">2. Stateless associations
accepted
one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">If the IDP agrees to process authentication
messages with<BR>no assoc_handle in section 8.</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">3. Types of claimed identifiers
accepted set of
<BR>
Http/Https/XRI</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Types of identifiers as enumerated in section
9.3.</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">4. Self-issued certificates
allowed one of
Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Applies to all https traffic. If 'no' here, then
Idp<BR>*probably* requires all https identifiers to chain up to <BR>known trust
roots, but that's intentionally not implied.</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">5. XRDS file must be
signed
one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Signature on the XRDS as per XMLDSIG. Keying
material not <BR>specified, since RP ultimately needs to make own decision
<BR>whether to trust keys used for such signature. </FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">6. XRDS must be retrieved over secure
channel one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">This does not imply SSL. See note on 4. about
trust roots.</FONT></DIV>
<DIV><BR><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">7. Accepted association session
types set of
<BR>
No-encryption/DH-SHA1/DH-SHA256</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">What types of session types can be used as
defined<BR>in section 7.4.3</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">8. Accept shared MAC
keys
one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">The spec is a bit muddled on what these imply in
<BR>section 9.2.2.2. </FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">9. RP must have
XRDS
one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Should the relying party be required to
advertise<BR>compliance with specific profiles as per section 11.</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">10. Accepted association types set
of HMAC-SHA1/HMAC-SHA256</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">What section 7.3. association types the IDP agrees
to<BR>use for signatures.</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">11. Association must be over secure
channel one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Whether the 7.4.1 request must take place on a
<BR>secure channel.</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face="Courier New">12. Allow IDP to select
identifier
one of Yes/No</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Whether the idp allows the identity to be set
to<BR></FONT><A
href="/exchweb/bin/redir.asp?URL=http://openid.net/identifier_select/2.0"
target=_blank><FONT
face="Courier New">http://openid.net/identifier_select/2.0</FONT></A></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Profiles<BR>--------<BR></FONT></DIV>
<DIV><FONT face="Courier New">The following two profiles "A" and "B" are
examples I think <BR>should be stated in the specification or a rider to
the same<BR>doc. The identifier of these profiles would be a URL that<BR>appends
to </FONT><A href="/exchweb/bin/redir.asp?URL=http://openid.net/auth/2.0/"
target=_blank><FONT
face="Courier New">http://openid.net/auth/2.0/</FONT></A>.</DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">The names "A" and "B" should of course be
discussed. I don't<BR>want to name then "low security" and "medium security"
as<BR>such distinctions carry implications and liabilities. (There<BR>is also a
risk of security creep that forces definitions to <BR>change over time -- what
is now 'medium security' could be <BR>'low security' in a few years, and
possibly 'useless security' <BR>in yet another few years. But the definition
will be stuck as<BR>'medium security' forever.)</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">I don't think (although I am not sure) compliance
to a specific <BR>profile should be mandatory in the OpenID auth spec
itself.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Profile A<BR></FONT><A
href="/exchweb/bin/redir.asp?URL=http://openid.net/auth/2.0/A"
target=_blank><FONT
face="Courier New">http://openid.net/auth/2.0/A</FONT></A><BR><FONT
face="Courier New"></FONT></DIV>
<DIV><FONT face="Courier New">1. Yes<BR>2. Yes<BR>3.
Http/Https/XRI<BR>4. Yes<BR>5. No<BR>6. No<BR>7.
DH-SHA1/DH-SHA256<BR>8. No<BR>9. No<BR>10.
HMAC-SHA1/HMAC-SHA256<BR>11. No<BR>12. Yes</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Profile B<BR></FONT><A
href="/exchweb/bin/redir.asp?URL=http://openid.net/auth/2.0/B"
target=_blank><FONT
face="Courier New">http://openid.net/auth/2.0/B</FONT></A><BR><FONT
face="Courier New"></FONT></DIV>
<DIV><FONT face="Courier New">1. Yes<BR>2. No<BR>3.
Http/Https/XRI<BR>4. Yes<BR>5. No<BR>6. No<BR>7.
No-encryption<BR>8. No<BR>9. No<BR>10. HMAC-SHA1/HMAC-SHA256<BR>11.
Yes<BR>12. Yes</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Processing<BR>----------<BR>In the specification,
we need to add how to handle error states <BR>when profiles are not
followed. Currently the protocol is quiet<BR>on how any such processing is
done. </FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">I propose the protocol should not contain any
graceful </FONT></DIV>
<DIV><FONT face="Courier New">degradation.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Next step would be to discuss if these profiles
make sense to<BR>the community and how to deal with errors when one party
becomes<BR>aware the other party is not compliant to a specific
profile.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">Thanks,</FONT></DIV>
<DIV><FONT face="Courier New">Hans</FONT></DIV>
<DIV> </DIV>
<DIV></FONT> </DIV></FONT></DIV></BODY></HTML>