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

[Takahiko Kawasaki]

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/20140620/24edd718/attachment.html>