[OpenID] OpenID Book draft version available for download

[Peter Williams]

10 points, to be used howsoever one sees fit.

 

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.

 

1.       At the outset, I wanted to learn about OpenID. I immediately
got a sales pitch on "Microsoft CardSpace", VeriSign(r) 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.

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.

In general, the 5 minute overview was far too technical. Its summary
form had me asking questions, which the material didn't answer.

 

2.       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.

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.

The material on smartcards felt like the person has never ever used
deployed a major smartcard system (such as UK banking, recently)!

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.

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. 

 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.

 

3.       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.

"Identity provider is the host 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.

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.

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.

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.


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.


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

 

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.



4.       Chapter 4 is well done. I wish its screenshots had been used in
chapter 1, so there would have been continuity and development.



5.       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!)

 

6.       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. 

 

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

 

8.       Needs to disappear, into an appendix. The book came to close at
7. Don't reopen it.























 

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Rafeeq Rehman
Sent: Wednesday, July 25, 2007 7:34 PM
To: general at openid.net
Subject: [OpenID] OpenID Book draft version available for download

 

All,

The draft PDF version of OpenID Book is available for download now at
http://www.openidbook.com

 

Rafeeq Rehman  

 

________________________________

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.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070728/7f24dee7/attachment-0002.htm>