On 8-Jun-07, at 2:26 PM, Drummond Reed wrote: > See my next message about this. It works identically to David's > examples > (just substitute these as reassignable and persistent identifiers) > except it > has the advantage that it does not require an extra round-trip for > discovery/verification of the persistent identifier (the Canonical ID) > because the client can verify from the identifiers themselves that the > provider of the reassignable identifier (the first one) is > authoritative for > the persistent identifier (the second one).
In essence, it would then be the same flow I detailed last week [1], would you agree? Specifically, the "canonical id verification" above is: > c) Verification of discovered information against auth response > fields: > strip_fragment(openid.claimed_id) == discovered claimed id So the fragment approach would match Josh's request for no extra discovery [2]. Allowing for more general canonical IDs would require a more complex verification process. Johnny [1] http://openid.net/pipermail/specs/2007-May/001767.html [2] http://openid.net/pipermail/specs/2007-June/001851.html _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
