[OpenID] Multiple Domains and State

[Peter Williams]

On my tiny phone screen I reread openid auth 2 spec, focusing on return-to and realm. I asked, if one applied classical security analysis, what service does each protocol element provide, as gleaned from the use of language.

Here are some pseudo facts

- return-to and realm are linked, as formal types. A protocol state is defined to be correct or not correct, as a function of the two types.

- realm is an rp identifier

- realm provides scope to a request, explicitely. No mention is made of scoped responses. 

- counsel is given on the op presentation to users of scoped request (realm) info.

- counsel on scope generality is given an counselling ops to guard on the topic of realms. Given that the vague warnings might mean something albeit imprecise, correct behaviour by an op is still hard to discern.

That's about it. Everything else has to be deduced by reading between the lines, trying to make one control design support another. But im intrepreting by doing this, if im truthful.

Given the obviousb skill of the writers, this ambuiguity in the method of the spec is obvipusly part of art of the method, designed to impel viral adoption probably. And, that is what makes openid so radical a departure and thus so interesting.

-----Original Message-----
From: Nate Klingenstein <ndk at internet2.edu>
Sent: Thursday, April 24, 2008 9:43 AM
To: Peter Williams <pwilliams at rapattoni.com>
Cc: Trey Long <trey at propeller.com>; general at openid.net <general at openid.net>
Subject: Re: [OpenID] Multiple Domains and State

Peter,

> A realm of *.com is only bad practice if one is equating openid  
> realms with cn wildcards in ssl server certs, or more formal per  
> recipient tokens enforced with crypto ad attribute matching logics.  
> As openid has little mainstream practice, its hard to say what is  
> good or bad.the jury has not even been called, let along sat to  
> hear the evidence.

I don't agree(and neither does the spec, explicitly calling this  
"dangerous").  It's not analogous to wildcarded certs because those  
are confirmed by possession of a corresponding private key.  There is  
no such confirmation in a bearer assertion like an OpenID response.

> If we look at openid realms, it not obvious that the construct is  
> an authorization control - guarding what rps may accept....
> Rather realm seems to being used (and who knows with openid!) the  
> 'notice of intended scope' by rp to user, in the law#4 sense,  
> enabling the user to then give notice of the limits to which the  
> notice of an expectation of privacy is being waived. In xacml  
> speak, its a obligation passing.

The intended scope of the assertion should be congruent with the set  
of RP's that will accept it, right?  The return URL/realm is included  
to allow the RP to protect itself from spoofing.

Sure, there's no way to stop an RP from accepting whatever they  
want.  If you want to be spoofed, as an OP, I can't prevent it.  I'd  
hope that most RP's intending to be spoofed will put other controls  
in place, such as a trust fabric.

Take care,
Nate.