[OpenID] openid and xpointer

[Johnny Bufu]

On 4-Feb-08, at 3:17 PM, Peter Williams wrote:

> I've hopefully reformated, to stop windows rewriting my url:
>
>> http: //example.com/?redirect=http://
>> www. example.org/file.xml#xpointer(id('calendar'))
>
> You say: Although they are defined as "Identifiers" (which are in  
> turn URIs),  the delegate / local_id can be any string the OP can  
> use to identify the user; that's because discovery is never  
> performed on a delegate identifier.
>
> So, if the OP's local process of user authentication were to  
> leverage/interpret information in that delegate string, it is  
> entirely entitled to do so. For example, if the op recognized that  
> the value is a uri-bound saml request, the op might redirect/bridge  
> to that saml website in order to complete the op's locally-defined  
> auth process, before sending the value to the RP (as in openid 1)?

Yes, I don't see why this couldn't work.


> Must the op send on the value from the xrd file as given, or can it  
> modify the value? In openid1 of course the sent value must be that  
> discovered by the rp, so it can match up the response with the  
> openid entered by the user.

The OP is free to respond with assertions containing different  
identifier(s) (openid.claimed_id and openid.identity), as long as the  
assertions pass the verification tests that the RP will perform.

One of this tests is comparing the delegate from the assertion  
(openid.identity) to the delegate obtained from discovery on  
openid.claimed_id.


> The key word in the above is match. Ascii matching is only one rule.

UTF-8 is specified when converting strings to/from bytes, so the  
match should be a UTF-8 string match.


> There are lots of other equivalence relations an rp might use,  
> given trust in a particular asserting op. Presumably, an rp might  
> signal support for extensions, allowing the op to use other than  
> the obvious matching rule. This would seem to get us close to  
> cardspace semantics, allowing the asserted token to signal its  
> authorization policy context (the matching/evidence validation model)


Johnny