<html>
<body>
<font size=3>Hans:<br><br>
Thanks for this excellent and absolutely essential analysis.
<br><br>
As to the proposed profiles, I feel you have done a fine job of keeping
it simple.<br><br>
Cordially, Joaquin<br><br>
<br>
Hans Granqvist wrote:<br>
</font><blockquote type=cite class=cite cite="">
<font face="Courier New, Courier" size=2> <br>
Hi<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>I propose the following
profiles as addition to OpenID auth <br>
spec. In the OpenID spirit, I have tried to keep these <br>
profiles as simple to implement as possible.<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" 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.<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Note: the list of
security variants is not implicitly complete.<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Some variants are
enforceable only via cooperation IDP/RP. This <br>
means there are sometimes no way in the protocol to detect <br>
whether a party complies to that variant of a profile. (For <br>
example, variant 5 listed below is of this type.)<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Also note that some
variants are identified because of possible <br>
future security threats.<br>
</font><font face="Arial, Helvetica" size=2> <br>
<br>
</font><font face="Courier New, Courier" size=2>Variants<br>
--------<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Notes on the variants
relate to draft #9.<br>
</font><font face="Arial, Helvetica" size=2> <br>
<br>
</font><font face="Courier New, Courier" size=2>1. Wildcards
allowed in trust
roots
one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Whether the IDP accepts
wild carded trust roots as specified<br>
in section 8.2<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>2. Stateless
associations
accepted
one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>If the IDP agrees to
process authentication messages with<br>
no assoc_handle in section 8.<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>3. Types of claimed
identifiers accepted set of <br>
Http/Https/XRI<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Types of identifiers as
enumerated in section 9.3.<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>4. Self-issued
certificates
allowed
one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>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.<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>5. XRDS file must
be
signed
one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>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. <br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>6. XRDS must be
retrieved over secure channel one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>This does not imply SSL.
See note on 4. about trust roots.<br>
</font><font face="Arial, Helvetica" size=2><br>
<br>
</font><font face="Courier New, Courier" size=2>7. Accepted
association session
types set of <br>
No-encryption/DH-SHA1/DH-SHA256<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>What types of session
types can be used as defined<br>
in section 7.4.3<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>8. Accept shared
MAC
keys
one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>The spec is a bit muddled
on what these imply in <br>
section 9.2.2.2. <br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>9. RP must have
XRDS
one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Should the relying party
be required to advertise<br>
compliance with specific profiles as per section 11.<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>10. Accepted association
types set of HMAC-SHA1/HMAC-SHA256<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>What section 7.3.
association types the IDP agrees to<br>
use for signatures.<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>11. Association must be
over secure channel one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Whether the 7.4.1 request
must take place on a <br>
secure channel.<br>
</font><font face="Arial, Helvetica" size=2> <br><br>
</font><font face="Courier New, Courier" size=2>12. Allow IDP to select
identifier
one of Yes/No<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>Whether the idp allows
the identity to be set to<br>
<a href="/exchweb/bin/redir.asp?URL=http://openid.net/identifier_select/2.0">
http://openid.net/identifier_select/2.0</a><br>
</font><font face="Arial, Helvetica" size=2> <br>
<br>
<br>
</font><font face="Courier New, Courier" size=2>Profiles<br>
--------<br>
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
<a href="/exchweb/bin/redir.asp?URL=http://openid.net/auth/2.0/">
http://openid.net/auth/2.0/</a></font>
<font face="Arial, Helvetica" size=2>.<br>
<br>
</font><font face="Courier New, Courier" size=2>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.)<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>I don't think (although I
am not sure) compliance to a specific <br>
profile should be mandatory in the OpenID auth spec itself.<br>
</font><font face="Arial, Helvetica" size=2> <br>
<br>
</font><font face="Courier New, Courier" size=2>Profile A<br>
<a href="/exchweb/bin/redir.asp?URL=http://openid.net/auth/2.0/A">
http://openid.net/auth/2.0/A</a></font>
<font face="Arial, Helvetica" size=2><br>
</font><font face="Courier New, Courier" size=2>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<br>
</font><font face="Arial, Helvetica" size=2> <br>
<br>
</font><font face="Courier New, Courier" size=2>Profile B<br>
<a href="/exchweb/bin/redir.asp?URL=http://openid.net/auth/2.0/B">
http://openid.net/auth/2.0/B</a></font>
<font face="Arial, Helvetica" size=2><br>
</font><font face="Courier New, Courier" size=2>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<br>
</font><font face="Arial, Helvetica" size=2> <br>
<br>
</font><font face="Courier New, Courier" size=2>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. <br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>I propose the protocol
should not contain any graceful <br>
degradation.<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font><font face="Courier New, Courier" size=2>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.<br>
</font><font face="Arial, Helvetica" size=2> <br>
<br>
</font><font face="Courier New, Courier" size=2>Thanks,<br>
Hans<br>
</font><font face="Arial, Helvetica" size=2> <br>
</font></blockquote></body>
</html>