[Openid-specs-ab] Question about pre-configured consent for the requested Claims

[Justin Richer]

One common way to handle this is to let the user save their response to the authorization request the first time it’s asked. This is often referred to as the “Trust On First Use”, or “TOFU” approach. Effectively, the client makes an auth request of the user (with no prompt command) and the user checks a box that says “don’t ask me about this client next time”. The server stores that decision and usually has a way for users to revoke that access grant at a future time through some kind of administration page. The next time the same client shows up and asks for the same access from the same user, the server looks up the stored grant decision and instead of prompting the user it simply passes it through.

What “prompt=none” is doing is creating a mode that enables clients to say “I’m just doing a background check — if the user is logged in and they’ve already granted me access, just give it to me; if not, don’t prompt them because this isn’t a call that’s visible to them right now.” So the answer comes back as either “yes” or “go ask the user yourself”, and in the latter case you fall back to an auth flow without “prompt=none” to make it work. 

 — Justin

On Jun 15, 2014, at 1:59 PM, Takahiko Kawasaki <daru.tk at gmail.com> wrote:

> I'm trying to understand the specification of OpenID Connect Core 1.0 and
> have a question about "pre-configured consent for the requested Claims"
> which is mentioned in "3.1.2.1. Authentication Request / prompt / none".
> 
> The description says as follows:
> 
>  none
>    The Authorization Server MUST NOT display any authentication
>    or consent user interface pages. An error is returned if an
>    End-User is not already authenticated or the Client does not
>    have pre-configured consent for the requested Claims or does
>    not fulfill other conditions for processing the request. The
>    error code will typically be login_required,
>    interaction_required, or another code defined in Section
>    3.1.2.6. This can be used as a method to check for existing
>    authentication and/or consent.
> 
> My question is "how does the Client pre-configure consent?"
> 
> Does "pre-configure consent" mean that the End-User grants consent to the
> Client in advance before the Client makes a request to the authorization
> endpoint? If so, it sounds to me that, to support consent pre-configuration,
> the Authorization Server has to provide a page where the End-User can edit
> which Claims to be released to which Client without consent when the Client
> accesses the authorization endpoint with 'prompt=none'.
> 
> Is my understanding correct?
> 
> Best Regards,
> Takahiko Kawasaki
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140617/11bea76d/attachment.asc>