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

Jared Hanson jaredhanson at gmail.com
Mon Aug 8 14:57:08 UTC 2022 

There seems to be enough real-world examples of this functionality that
it's worth standardizing the pattern.  `idp_hint` seems sensible to me, but
I'm relatively unopinionated on the particular serialization.

While I suspect that the value in many cases will be interpreted/defined by
the IDP processing the /authorize request, there's some rationale for
establishing a registry for representing well-known target IDPs.  This need
also arises in W3C Credential Management when using `FederatedCredentials`,
which need to identify a particular provider.  The guidance there is to use
the origin the provider uses for sign in (see:
https://www.w3.org/TR/credential-management-1/#provider-identification).
This often, but not always, maps to the `iss` value for providers using
OIDC - but ultimately it is up to the implementation to map a provider to
the specific protocol that provider uses.

Perhaps when the parameter is specified, an IANA registry could be
established for identifying IDPs, with guidance that the registered values
SHOULD be used as the value of the `idp_hint` parameter.  Credential
Management could likewise recommend the use of registered values.

On Mon, Aug 8, 2022 at 6:22 AM Mischa Salle via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> On Mon, Aug 08, 2022 at 09:05:04AM -0400, George Fletcher wrote:
> > My concern with using 'login_hint' is that the core OIDC spec says that
> the
> > login_hint is a "Hint to the Authorization Server about the login
> > identifier the End-User might use to log in (if necessary)."
> >
> > Given this hint is about the end-user it also doesn't feel appropriate to
> > use for the identification of a federated IDP. :)
>
> true, and I see your point, but looking up the IdP from the email
> address' domain doesn't seem so different from specifying the IdP's
> entityID I'd say? Also, the spec says it's a hint about the identifier,
> i.e. not per se directly about the end-user themselves?
>
> Mischa
>
> >
> > Thanks,
> > George
> >
> > On Mon, Aug 8, 2022 at 8:52 AM Mischa Salle via Openid-specs-ab <
> > openid-specs-ab at lists.openid.net> wrote:
> >
> > > Hi all,
> > >
> > > to comment on both suggestions, namely using amr or acr_values, both
> > > seem to be not really the right ones although I don't think the spec
> > > would forbid it if I read the core spec carefully?
> > > amr is describing the method such as password or yubikey etc. and which
> > > IdP to use is not really such a method I'd say.
> > > Similarly Authentication Context Classes are typically used for
> > > assurance although you can of course say that an IdP is an
> > > authentication context (see also
> > >
> > >
> https://urldefense.com/v3/__http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGSbwC0q0$
> > > for the initial list in SAML).
> > > On the other hand, we were wondering whether login_hint would be the
> > > more logical option?
> > >
> > > Mischa
> > >
> > >
> > > On Wed, Aug 03, 2022 at 12:57:21PM -0600, David Waite via
> Openid-specs-ab
> > > wrote:
> > > > So this isn’t a hint for a RP/client to know which OP/AS to use, but
> for
> > > an RP/client to tell an OP/AS which upstream OP/AS to use?
> > > >
> > > > Would it make sense to represent as an AMR?
> > > >
> > > > -DW
> > > >
> > > > > On Aug 2, 2022, at 4:52 PM, Vittorio Bertocci <
> > > vittorio.bertocci at okta.com> wrote:
> > > > >
> > > > > Well, there’s no guarantee that the IdP is connected to the OP/AS
> via
> > > OIDC- in fact protocol transition is super common. The actual IdP might
> > > have no notion of issuer.
> > > > >
> > > > > On Tue, Aug 2, 2022 at 15:50 David Waite <
> david at alkaline-solutions.com
> > > <mailto:david at alkaline-solutions.com>> wrote:
> > > > >>
> > > > >>   This message originated outside your organization.
> > > > >>
> > > > >>
> > > > >> But wouldn’t it usually be the issuer?
> > > > >>
> > > > >> Sent from my iPhone
> > > > >>
> > > > >> > On Aug 2, 2022, at 9:50 AM, George Fletcher via Openid-specs-ab
> <
> > > openid-specs-ab at lists.openid.net <mailto:
> openid-specs-ab at lists.openid.net>>
> > > wrote:
> > > > >> >
> > > > >> > 
> > > > >> > 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.
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> > > > _______________________________________________
> > > > Openid-specs-ab mailing list
> > > > Openid-specs-ab at lists.openid.net
> > > >
> > >
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$
> > >
> > >
> > > On Wed, Aug 03, 2022 at 10:36:27AM -0400, Brock Allen via
> Openid-specs-ab
> > > wrote:
> > > > FWIW, we've used acr_values with a formatted value "idp:name_of_idp"
> > > approach.
> > > >
> > > > Similarly we also have used acr_values to pass tenant requirements
> with
> > > a formatted "tenant:name_of_tenant" for multi-tenant OP/AS scenarios.
> > > >
> > > >
> > > > -Brock
> > > > On 8/3/2022 10:32:09 AM, George Fletcher via Openid-specs-ab <
> > > openid-specs-ab at lists.openid.net> wrote:
> > > > So it seems that we have many implementations of this concept. I
> think
> > > what I'm looking for is whether we should try and standardize a
> parameter
> > > for this use case, or just leave each domain to define their own way to
> > > enable this functionality.
> > > >
> > > > Thanks,
> > > > George
> > > >
> > > > On Wed, Aug 3, 2022 at 10:22 AM Marcus Hardt via Openid-specs-ab <
> > > openid-specs-ab at lists.openid.net [mailto:
> openid-specs-ab at lists.openid.net]>
> > > wrote:
> > > >
> > > > Hi There,
> > > >
> > > > we've gone through this exercise within the AARC project. The
> scenario is
> > > > slightly more complex (we have this proxy architecture, and we're
> > > > protocol-agnostic-enough so that's also implementable in SAML), but I
> > > > think your use-case is fully covered in AARC-G061 [1].
> > > >
> > > > [1]
> > >
> https://urldefense.com/v3/__https://aarc-community.org/guidelines/aarc-g061/__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGWHgjLyk$
> > > [
> > >
> https://urldefense.com/v3/__https://aarc-community.org/guidelines/aarc-g061/__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGWHgjLyk$
> > > ]
> > > >
> > > >
> > > > The longer part of the story is, that we originally had the 'idphint'
> > > > parameter, which was too loosely defined. Hence we defined it as
> > > > 'aarc_idp_hint'.
> > > >
> > > > Essentially, it is a single-values url-encoded StringOrURI.
> > > >
> > > > The actual value is not specified, but I think it is generally
> assumed to
> > > > refer to either an 'iss' or in SAML to an 'entityID'.
> > > >
> > > >
> > > > If this aarc recommendation is not enough or too much from your
> > > > perspective, I think the original authors could be motivated to
> > > > participate in the discussion here.
> > > >
> > > > Best,
> > > > Marcus.
> > > >
> > > >
> > > > On 02. Aug 2022 11:22, George Fletcher wrote:
> > > > > 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.
> > > > >
> > > > >
> > > > >
> > > > > -------------- next part --------------
> > > > > An HTML attachment was scrubbed...
> > > > > URL: <
> > >
> https://urldefense.com/v3/__http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/74656401/attachment.html__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGrl20idE$
> > > [
> > >
> https://urldefense.com/v3/__http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/74656401/attachment.html__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGrl20idE$
> > > ]>
> > > > >
> > > >
> > > > --
> > > > Marcus.
> > > > _______________________________________________
> > > > Openid-specs-ab mailing list
> > > > Openid-specs-ab at lists.openid.net [mailto:
> > > Openid-specs-ab at lists.openid.net]
> > > >
> > >
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$
> > > [
> > >
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$
> > > ]
> > > >
> > > >
> > > >
> > > > 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://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$
> > >
> > > > _______________________________________________
> > > > Openid-specs-ab mailing list
> > > > Openid-specs-ab at lists.openid.net
> > > >
> > >
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$
> > >
> > >
> > >
> > > --
> > > Nikhef                      Room  1.14
> > > Science Park 110            Tel.  +31-6-4681 2202
> > > 1098 XG Amsterdam           Fax   +31-20-592 5155
> > > The Netherlands             Email msalle at nikhef.nl
> > >   __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
> > > _______________________________________________
> > > Openid-specs-ab mailing list
> > > Openid-specs-ab at lists.openid.net
> > >
> > >
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$
> > >
> >
> > ______________________________________________________________________
> >
> >
> >
> > 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.
> >
> >
> >
>
> --
> Nikhef                      Room  1.14
> Science Park 110            Tel.  +31-6-4681 2202
> 1098 XG Amsterdam           Fax   +31-20-592 5155
> The Netherlands             Email msalle at nikhef.nl
>   __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://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/20220808/ff9196d6/attachment.html>

More information about the Openid-specs-ab mailing list