[OpenID] Scheme in OP-Local ID
Peter Williams
pwilliams at rapattoni.com
Thu Mar 6 22:20:37 UTC 2008
Recalling previous discussion, on openid consumer obligations when
handling identity signals in id_res - occurring obviously after a
previous instance of openid discovery.
The topic was: What to do about a further round of openid discovery, in
the special case that asserting party does not reply with an assertion
about (exactly) the same id cited in the consumer's request (which was
presumably the normalized final destination URL from the first round of
discovery)
> -----Original Message-----
> From: Johnny Bufu [mailto:johnny at sxip.com]
> Sent: Thursday, September 06, 2007 1:16 PM
> To: Peter Williams
> Cc: Jack; OpenID List
> Subject: Re: [OpenID] Scheme in OP-Local ID
>
>
> On 6-Sep-07, at 12:56 PM, Peter Williams wrote:
>
> >> The claimed_id has only one form - the normalized one.
> >
> > [Peter Williams] if the claimed_id that comes back in check_id
> > response
> > is not octet-identical to the normalized user input value (in the
> > solicited auth flow of OpenID Auth), shall one perform a new round
of
> > discovery in the check_id resp verification logic (both dumb and
> > intelligent varieties)?
>
> (Assuming you meant id_res response).
>
> Yes: if the asserted claimed_id is different than what was discovered
> starting from the user input, then the assertion is about a different
> identifier and must be treated as such (discovery on the new
> claimed_id, verification against assertion data, etc.)
>
> > I'd expect the result of discovery performed against this
> > claimed_id to
> > identify amongst its HTML/XRDS OPs the exact URL of the OP selected
> > earlier from the discovery against the normalized user input value.
>
> What has been discovered earlier has no relevance since the assertion
> is about a different identifier. Assertion data must be compared with
> the data discovered from the claimed_id in the assertion, not the set
> discovered from the initial user-input.
>
> > We cannot make the assumption that XRDS metadata for normalized user
> > input URL will be identical with the XRDS metadata for the
> > claimed_id in
> > the check_id response
>
> That's the equivalent of saying "we cannot make the assumption that
> verification of discovered information will succeed all the time,
> even when the XRDS discovery data is wrong or the OP issues bad
> assertions".
>
> (With that said, in the case of URLs the calimed_id is not taken from
> the XRDS).
>
>
> Johnny
More information about the general
mailing list