Wrapping Up Proposals

Dick Hardt dick at sxip.com
Wed Oct 4 02:51:16 UTC 2006


On 2-Oct-06, at 4:46 PM, Recordon, David wrote:
> * IdP-supported Delegation
> (http://openid.net/pipermail/specs/2006-September/000002.html)
> 	Postponed as it changes a fundamental way in which delegation is
> architected in that currently the IdP has no way to know that  
> delegation
> is being performed

0

>
> * Rename trust_root to realm
> (http://openid.net/pipermail/specs/2006-September/000018.html)
> 	Accepted (+3, 0, -0) for draft 10, needs to be changed in the
> spec.

+1 - better to get clarity sooner then later

>
> * Remove SIGNALL
> (http://openid.net/pipermail/specs/2006-September/000018.html)
> 	Accepted (+4, 0, -1) for draft 10, needs to be changed in the
> spec.

+1 - no added value

>
> * Standard multivalue parameter mechanism
> (http://openid.net/pipermail/specs/2006-September/000139.html)
> 	Still being discussed, need feedback on Dick's follow-up at
> http://openid.net/pipermail/specs/2006-October/000149.html

+1 - no ne wcomplexity, simple documentation of how things are now  
and provides clarity for future

>
> * Request nonce and name
> (http://openid.net/pipermail/specs/2006-October/000149.html)
> 	Still being discussed, openid.nonce has been renamed to
> openid.response_nonce for draft 10.  Agreement to keep the name  
> "nonce",
> little discussion on adding a request nonce.

+1 - ok with nonce being in name (few people know what it means  
though), think response should be optional

>
> * Authentication age
> (http://openid.net/pipermail/specs/2006-September/000141.html)
> 	Still being discussed, varying opinions on if the spec mandates
> this will IdPs cooperate.  Proposal of having it as an extension.

+1 - per other email, let's get the feature in there. The IdP is  
already managing session age. Having it as an extension is going to  
add complexity to RP code as they have to discover if they can have  
that as a parameter. This seems like huge overhead to determine a  
single parameter

>
> * Bare response / bare request
> (http://openid.net/pipermail/specs/2006-September/000142.html)
> 	Still being discussed


+1 - mainly clarification of what is already likely to work. If I  
send a request that has no return_to, what will an IdP do? better to  
define. Already need to have code to deal with it.





More information about the specs mailing list