[Openid-specs-ab] [External Sender] Re: IDP Hint for /authorization requests

[Vittorio Bertocci]

I see the analogy from the functional perspective. To me the difference is
that there’s no need to have a common representation of a particular user
for interop purposes, while it is the case for providers (some well known
singletons like social providers) hence the expectations for idp_hint would
be different than for login_hint (the former would be expected to do more
than the latter out of the box)

On Tue, Aug 2, 2022 at 08:50 George Fletcher <george.fletcher at capitalone.com>
wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> All very relevant points. I was looking at it more as idp_hint=<string>
> where <string> is defined by the specific OP and explicitly left out of
> scope of the spec. All it does is standardize the name of the parameter and
> let each implementation define its own syntax. This can be useful for
> places that don't want to "extend" the specs for their own uses. Otherwise,
> I agree it doesn't provide any "interop" benefits.
>
> Thanks,
> George
>
> On Tue, Aug 2, 2022 at 11:35 AM Vittorio Bertocci <vittorio at auth0.com>
> wrote:
>
>> Some providers do support parameters with a similar semantic. The tricky
>> part is that the value will be specific to the AS (eg there’s no standard
>> identifier for Facebook or your local Ping IdP) hence the interop
>> advantages of standardizing the parameter might not be as significant.
>> Other potential complication is if there’s some protocol transition, eg jf
>> thenhint needs to be propagated thru further legs hence re-wrapped in
>> semantic equivalents in the target protocol (eg wtrealm in wsfed), also
>> something implementation specific.
>> I would not be against standardizing, I see no harm w it, it’s more of a
>> cost/benefit consideration of the time spent on doing so vs benefit of it.
>>
>>
>> On Tue, Aug 2, 2022 at 08:23 George Fletcher via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> *This message originated outside your organization.*
>>>
>>> ------------------------------
>>>
>>> Hi,
>>>
>>> I know I've mentioned this in the past and wanted to bring it up again.
>>> If an OpenID Provider allows for federation with multiple IDPs, there are
>>> times the client wants to "tell" the OP which of those federated IDPs to
>>> use.
>>>
>>> In a social login context, this can allow the client to specifically
>>> tell the OP to use Facebook for authenticating this user. However, this
>>> pattern is used in many other contexts.
>>>
>>> Any interest in writing a very small spec to enable an 'idp_hint'
>>> parameter that can be passed as part of the /authorization request? I
>>> suppose this could also go to the IETF as it's not specific to ODIC.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> George
>>> ------------------------------
>>>
>>> The information contained in this e-mail is confidential and/or
>>> proprietary to Capital One and/or its affiliates and may only be used
>>> solely in performance of work or services for Capital One. The information
>>> transmitted herewith is intended only for use by the individual or entity
>>> to which it is addressed. If the reader of this message is not the intended
>>> recipient, you are hereby notified that any review, retransmission,
>>> dissemination, distribution, copying or other use of, or taking of any
>>> action in reliance upon this information is strictly prohibited. If you
>>> have received this communication in error, please contact the sender and
>>> delete the material from your computer.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!NsbluRoqujGBcJLbCZrBXFvdHGrE0JHY7j72sEIagqXp9U0nQW4XphVkFACl_o9RPQ7q1GbnG_rjt9gocuKxzaBFXg$>
>>>
>> ------------------------------
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/fa7d9315/attachment.html>