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

[Nat Sakimura]

Actually, there are more context to it. 

In enterprise scenarios, it is possible that the company policy maker decides what can be provided to the system. This could be treated as an out of bound consent. Similarly, even in consumer scenario, request fulfilling legitimate interest or 'conditions for processing' can be deemed to have gathered the consent of the user by his action. Under such circumstances, the user should not be presented by the consent screen. 

This can be achieved by the client registering the request uri with hash as fragment and having it white listed by the relevant authority. 

=nat via iPhone

> On Jun 18, 2014, at 17:01, Takahiko Kawasaki <daru.tk at gmail.com> wrote:
> 
> Dear Justin,
> 
> Thank you very much for your detailed explanation. I could understand
> the context and the timing at which pre-configuration should be
> performed.
> 
> Best Regards,
> Takahiko Kawasaki
> 
> 
> 2014-06-18 7:55 GMT+09:00 Justin Richer <jricher at mit.edu>:
>> 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab