Improving OpenIDs use of cryptography 1 - using a MAC

Ben Hyde bhyde at
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 <-> 

  - ben

  I forecast sunny weather!

More information about the yadis mailing list