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

[Nat Sakimura]

I would say that there are multiple ways of doing it, though request uri was actually designed for this purpose. 

=nat via iPhone

> On Jun 19, 2014, at 17:41, Takahiko Kawasaki <daru.tk at gmail.com> wrote:
> 
> Dear Nat,
> 
> Thank you for your additions. My understanding is now that pre-configured consent can be given to the Client in various ways but the means are out of scope for OpenID Connect specification.
> 
> Best Regards,
> Takahiko Kawasaki
> 
> 
> 2014-06-19 6:08 GMT+09:00 Nat Sakimura <sakimura at gmail.com>:
>> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140619/ba6df8b6/attachment.html>