<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:2114400411;
mso-list-type:hybrid;
mso-list-template-ids:-609429842 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='color:#1F497D'>10 points, to be used howsoever
one sees fit.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Being way too locked down in its
use of distribution media, I cannot easily supply detailed notes or review points
– as all the reader’s reviewing tools are disabled by the author’s/publisher’s
security policy. Sorry – I take notes, when I read or review; always have,
will always want to; particularly audio notes. I Thus felt too controlled by
the form of delivery (since I’m a note taker). The overall reading
experience in this media felt a little an OP that aims “to control one in
one’s own interest” – limiting you on how you SHALL be
limited when using one’s OpenID at only “OP-certified sites,
perhaps! If this media experience is an illustration of what the culture of OpenID
will be, the document is actually meta-useful - in this regard.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>At the outset, I wanted
to learn about OpenID. I immediately got a sales pitch on “Microsoft CardSpace”,
VeriSign® PIP credentialing, and the future interplay between those latter two,
non-OpenID community initiatives. And, we learn, there is yet much more to come
on those topics.<br>
<br>
No. If I pay for a book on OpenID, I want to mostly read about OpenID! I
already read an excellent (Microsoft Press) book on WS-Trust, and the
ws-federation binding. A couple of implementation commentaries is of
course fine, addressing interesting hookups with the infocard selector protocol,
the secure storage option of Windows, and the trusted desktop. But don’t bias
the reader, please. Right now, a technical evaluator would assume that an OpenID
implementation will require one implements the ws-trust protocol.<br>
<br>
In general, the 5 minute overview was far too technical. Its summary form had me
asking questions, which the material didn’t answer.<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>Chapter nicely
starts out discussing what token-centric A&A schemes are. There is a
little confusion in distinguishing the identity properties on OpenID from the
token-making power of one or more providers attached to that OpenID. One could
be left with the impression that the OpenID is itself a token. Whilst this kind
of conceptual analysis makes identity as tokens a philosophical possibility, it
would need a lot more material to make that case. In a book of this type, I’m
not sure it fits. Perhaps leave such topics to academic treatise works.<br>
<br>
The material on OTP is a little disingenuous. Realty is already making advanced
used of OTPs generated on smartphone applets; removing the notion of carrying
around multiple little key fobs. A little reality check may be advised.<br>
<br>
The material on smartcards felt like the person has never ever used deployed a major
smartcard system (such as UK banking, recently)!<br>
<br>
I was stunned to suddenly see 2.6 introduced, introduced federations and
websso. Its described as a magic solution to all the previous problems hinted
at in the previous sections in the chapter. I kind of started to wonder about
the author… a little. A little too much Potter, recently? Not a lot got
said.<br>
<br>
The chapter loses even more focus, starting to discuss identity management in
general. The Federation Identity Management, then Directory infrastructure as
Authentication Frameworks, and then finally, OpenID/Yadis/Higgins etc as the
newest schemes. <br>
<br>
In review terms, the foundation has not been given to make these claims.
This is supposed to be a foundation chapter, furthermore. In including
the OpenID claims as part of establishing the foundation, one has ended up
making the case that the books main topics are only foundational, in essence.<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>Chapter 3 intends to
describe the OpenID Auth protocol, if I understood the scope. Much like
describing the SSL protocols, it lays the baseline for then showing how a[ny]
protocol can support such as inter-system interworking. In summary, the discussion
strays from a protocol description. It gets far too deep into the philosophy of
the protocol design, and I find myself being induced to argue with the
interpretation , rather than reading a good solid reference chapter about a
bunch of messages and state machines.<br>
<br>
</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:black'>“Identity provider is the host</span><span style='color:
#1F497D'> where a user’s credentials are stored….”. Hmm. This
is an highly restrictive way to view the scope of an OP! While it may be
true for a self-issued card in a cardspace enabled OP backend local authentication
scheme, in the case that that very same host is also issuing the assertions/tokens,
this is hardly an adequate definition for the general case. Note also the
conceptual shift on orientation from the earlier discussion of token-making
architectures: now the Provider is merely introduced as being a mere mechanism
for Consumers to “validate” IDs. Later, the notion is refined
further – one tying validation to the proof of “ownership” of
an UCI. Then I found myself asking: so just who “owns”
rrid.pip.verisignlabs.com? VeriSign or the subscriber? Is the provider’s token’s
assertion about ownership being made by VeriSign (the OP in question) or the
user? Later comments introduce the notion that users may or may not “own”
their IDs. Only those who do “own”, get portability.<br>
<br>
3.1.3 says there are three major components…. What happened to #4 , the
user introduced moments earlier? In a specifically UCI-focused design, I would
not expect an architect to exclude the user from the “system”, as
in classical IT system modeling which reduces people to their User Agents. This
seems a backwards round way of looking at the world – akin to the world
of MMI/HCI before user-centric design methodologies came into that analogous field.
But, I’m being a little theoretical, here. As a review point, however, I do
wonder if I’m still reading hard fact, or getting architectural opinion
and interpretation.<br>
<br>
I still don’t get direct vs indirect distinctions (from what is some quite
traditional discussion). If direct means there is backchannel between websites,
then please just say so. If indirect means that inter-website message transfer
occurs via the browser as a communication intermediary, then just say so. If
these terms mean something else, describe it in terms other than POST vs
redirect/forms, GETs.<br>
<br>
On dumb/smart, try to avoid the term connection. Folks running internet data
centers have fixed notions about connections, sessions, SSL session state, load
balancing…and therefore high-availability flow-based routing by terabit NICs.
Persistent site-session cookies (or similar) issued to authorize access to some
backend website must be distinguished from the routing/switching/flow-management
communication infrastructure implemented by data centers etc. Caching of openID
Auth mac-keys in a security MIB accessible to the Consumer agent pool must be
made a clearer topic of discussion, distinguished from SSL-sessionids,
authorization/session-cookies issued by websites, and of course those pesky
data-center sessions.<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><br>
At the end of the day, the chapter seems to convey the notion that smartmode is
but an optimization of dumb mode: avoiding the need to perform a key agreement
act for each run of the protocol, and or avoid the need to ask the provider:
did you just sign the assertion I received. But I had to work hard to get this critical
notion out of the text.<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><br>
OK. I’m disappointed, overall in the chapter. The book is no clearer than
the spec in portraying the direct/indirect dumb/smart issue set. Having read
the code, I do now understand what are now easy, and valuable distinctions …
but it wasn’t from the descriptions given, here or in the base spec docs
>From some hints in the chapter, I’m not really supposed to understand yet
– I’m supposed to wait for chapter 5, where the packet sniffing
traces are given. Chapter 3 comes across just a (confusing) overly-technical overview
of the core system flows. So, this is the second time I wanted to get clear
info on this topic area from the book,… and I’m still frustrated<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'>Some notes, added upon a
second reading: Having criticized the early sections, from section 3.4 onwards,
note, the chapter really does improve remarkably, into what I had expected. It does
what was billed at the outset of the chapter, in these sub-topic areas. I do
wish it had explained WHY one might choose to encrypt the hmac-signature! One
is left with the feeling that (and here the author does a good job) that the
whole association process is like a poor man’s SSL handshake and session
management – which one is advised then to use anyways! The lack of clarity
in describing the various bindings used really does the presentation of the security
handshake state machine a dis-service. Sections 3.7 and later etc don’t really
belong in this chapter.<br>
<br>
<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>Chapter 4 is well
done. I wish its screenshots had been used in chapter 1, so there would have
been continuity and development.<br>
<br>
<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>Chapter 5 is similarly
well done, with the same comments as on chapter 4. 5.4 ought to be in
chap 3, where it belongs (and where I missed it!)<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>6.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>Chapter 6 was ok. It
was an example driven description. It would be nice to see a more expressive
extension architecture portrayal. One example showed enhancing OpenID Auth,
another the YADIS file. I didn’t feel that the author was convincing me
that the framework for extensibility was itself sound, as the protocol’s
usage and applicability takes off – possibly into areas where there will inevitably
be a need for private extensions, that do not go into the meritocracy forum or decision
making process. <o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>7.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>I recognize chapter
7 as a… horizons chapter. This is fitting. It finally declares SAML
as the enemy (hehe!), making some juvenile claims – and possibly embarrassing
VeriSign (a SAML founder). Consider your image, author! It portrays
OpenID in the enterprise or cross-enterprise space as something that is tied to
cross-domain directory management. I turned off – as one reader who has
had quite enough of that particular line of coolaid after 20 years of it. Be
careful with the tone, here. Don’t bias horizon presentation with too
strong a presentation of the author’s opinions about the way you believe the
future SHOULD go, assuming OpenID takes off. That is the reader’s prerogative<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>8.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>Needs to disappear,
into an appendix. The book came to close at 7. Don’t reopen it.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Rafeeq
Rehman<br>
<b>Sent:</b> Wednesday, July 25, 2007 7:34 PM<br>
<b>To:</b> general@openid.net<br>
<b>Subject:</b> [OpenID] OpenID Book draft version available for download<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>All,<o:p></o:p></p>
<p class=MsoNormal>The draft PDF version of OpenID Book is available for
download now at <a href="http://www.openidbook.com">http://www.openidbook.com</a><o:p></o:p></p>
<p class=MsoNormal> <o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Rafeeq
Rehman</span> <o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;color:#4F81BD'><o:p> </o:p></span></p>
<div class=MsoNormal align=center style='text-align:center'>
<hr size=2 width="100%" align=center>
</div>
<p class=MsoNormal><span style='font-size:8.0pt;font-family:"Arial","sans-serif"'>This
message and any attachments contain confidential information intended for a
specific individual, a specific purpose, and is protected by law. It can't
be used or forwarded to anyone for any other purpose. - If you are not the
intended recipient, you should delete this message and are hereby notified that
any disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.</span><span style='font-size:8.0pt'><o:p></o:p></span></p>
<p class=MsoNormal> <o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>