Improving OpenIDs use of cryptography 1 - using a MAC
bhyde at pobox.com
Fri Jun 3 07:44:38 PDT 2005
On Jun 1, 2005, at 10:07 PM, Paul Crowley wrote:
> Instead of connecting to the ID server to fetch the DSA public key,
> each ID consumer will agree their own MAC secret with the ID server.
One thing I sort of like about the design as it stands is the lack of
any state/account/relationship between the client and id servers. The
ID server does not need to provision and maintain accounts for the
client servers; which is good because as soon as you do provision such
accounts clever ideas will stream into the design space for things to
do with that account.
As it stands the first message that a server ever sends the ID server
could well be the request for an assertion.
I see in later notes in this thread an outline for a cool scheme that
creates a very minimal amount of state; just enough to get the shared
secret provisioned. I view that as a very light weight account; you
need to provision that secret/account prior to requesting the first
I tend toward prefer using of the public/private key rather than a
shared secret. The computation cost is buying something - a near zero
client-server<->id-server relationship. If we want to move away from
zero then think you need to admit there are a lot of nice things
enabled by creating a real account relationship between those two
parties, then go ahead and provision real accounts, then exchanging a
secret is easy.
I'd prefer not to introduce real accounts between the client-server <->
I forecast sunny weather!
More information about the yadis