[Openid-specs-ab] Current Summary of Issues

Nat Sakimura sakimura at gmail.com
Sat Jun 12 09:40:27 UTC 2010

op_endpoint was returned from the OP in draft11, but I think it should
be removed, because it can be tampered and creates a risk to the RP.
It can store it in the cookie, or 'state' variable etc.


On Tue, Jun 8, 2010 at 4:45 PM, Nat Sakimura <sakimura at gmail.com> wrote:
> Here are the Current Summary of Issues collected on the draft.
> 1. Error codes in Negative Assertions needs to be defined.
> - "invalid code"
> - "invalid client_id"
> - "invalid secret_type"
> - "expired code"
> (Currently, it just defines "cancel" per OpenID 2.0)
> 2. If the "code" in the direct assertion req is invalid, the OP cannot
> understand "atype"
> opt.1: Make the error to be always JSON
>   => Javascript clients may choke
> opt.2: Have atype in the request as well.
>   => this means we have to define error in other atype like SAML, etc.
> From the point of view of the simplicity, opt.1 looks better to me.
> 3. Define "id" in the request file.
> - I need to understand the semantics. It would be better to have more
> descriptive name.
> 4. Semantics of "issued_at" and "expires_in" needs clarification.
> - Are they the same for all of 1) Assertion, 2) Artifact, and 3) Access
> Token?
> - If not so, is it not better to define all of them?
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en

Nat Sakimura (=nat)

More information about the Openid-specs-ab mailing list