<div dir="ltr">The hint to the intended IDP is often used to actually override whatever info you might be extracting from login_hint. Think of federated cases where guest users are allowed: you might want to say to the OP that you want a token from <a href="http://domain1.com">domain1.com</a>, the fact that you want that for <a href="mailto:user@domain2.com">user@domain2.com</a> (which might be the mnemonic identifier for both an account in domain1 and a guest one in domain2) is a separate and semi-independent notion.<div>Also, there might be no user hint at all. Think of the case in which a RP expects users from Europe and Japan, housed in different regional OP deployments, and uses a heuristic (eg IP of the requestor) to skip the HRD page and send the request straight to the OP of the region corresponding to the caller, without knowing anything about the user yet (don't overindex on the example, yes there will be cases where the heuristic is wrong (user traveling) and a remediation path will be required, but the details are out of scope here :)). </div><div>To stress: I think the parameter has obvious uses and utility. I am only wondering how much real interop having an agreed upon param name will lead to in concrete examples.Not saying it's zero at all, only that I wouldn't take it for granted. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 8, 2022 at 6:22 AM Mischa Salle via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This message originated outside your organization.<br>
<br>
<br>
On Mon, Aug 08, 2022 at 09:05:04AM -0400, George Fletcher wrote:<br>
> My concern with using 'login_hint' is that the core OIDC spec says that the<br>
> login_hint is a "Hint to the Authorization Server about the login<br>
> identifier the End-User might use to log in (if necessary)."<br>
> <br>
> Given this hint is about the end-user it also doesn't feel appropriate to<br>
> use for the identification of a federated IDP. :)<br>
<br>
true, and I see your point, but looking up the IdP from the email<br>
address' domain doesn't seem so different from specifying the IdP's<br>
entityID I'd say? Also, the spec says it's a hint about the identifier,<br>
i.e. not per se directly about the end-user themselves?<br>
<br>
Mischa<br>
<br>
> <br>
> Thanks,<br>
> George<br>
> <br>
> On Mon, Aug 8, 2022 at 8:52 AM Mischa Salle via Openid-specs-ab <<br>
> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> <br>
> > Hi all,<br>
> ><br>
> > to comment on both suggestions, namely using amr or acr_values, both<br>
> > seem to be not really the right ones although I don't think the spec<br>
> > would forbid it if I read the core spec carefully?<br>
> > amr is describing the method such as password or yubikey etc. and which<br>
> > IdP to use is not really such a method I'd say.<br>
> > Similarly Authentication Context Classes are typically used for<br>
> > assurance although you can of course say that an IdP is an<br>
> > authentication context (see also<br>
> ><br>
> > <a href="https://urldefense.com/v3/__http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGSbwC0q0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGSbwC0q0$</a><br>
> > for the initial list in SAML).<br>
> > On the other hand, we were wondering whether login_hint would be the<br>
> > more logical option?<br>
> ><br>
> > Mischa<br>
> ><br>
> ><br>
> > On Wed, Aug 03, 2022 at 12:57:21PM -0600, David Waite via Openid-specs-ab<br>
> > wrote:<br>
> > > So this isn’t a hint for a RP/client to know which OP/AS to use, but for<br>
> > an RP/client to tell an OP/AS which upstream OP/AS to use?<br>
> > ><br>
> > > Would it make sense to represent as an AMR?<br>
> > ><br>
> > > -DW<br>
> > ><br>
> > > > On Aug 2, 2022, at 4:52 PM, Vittorio Bertocci <<br>
> > <a href="mailto:vittorio.bertocci@okta.com" target="_blank">vittorio.bertocci@okta.com</a>> wrote:<br>
> > > ><br>
> > > > Well, there’s no guarantee that the IdP is connected to the OP/AS via<br>
> > OIDC- in fact protocol transition is super common. The actual IdP might<br>
> > have no notion of issuer.<br>
> > > ><br>
> > > > On Tue, Aug 2, 2022 at 15:50 David Waite <<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a><br>
> > <mailto:<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>>> wrote:<br>
> > > >><br>
> > > >> This message originated outside your organization.<br>
> > > >><br>
> > > >><br>
> > > >> But wouldn’t it usually be the issuer?<br>
> > > >><br>
> > > >> Sent from my iPhone<br>
> > > >><br>
> > > >> > On Aug 2, 2022, at 9:50 AM, George Fletcher via Openid-specs-ab <<br>
> > <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> <mailto:<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>><br>
> > wrote:<br>
> > > >> ><br>
> > > >> > <br>
> > > >> > All very relevant points. I was looking at it more as<br>
> > idp_hint=<string> where <string> is defined by the specific OP and<br>
> > explicitly left out of scope of the spec. All it does is standardize the<br>
> > name of the parameter and let each implementation define its own syntax.<br>
> > > >><br>
> > > >><br>
> > > >><br>
> > ><br>
> ><br>
> > > _______________________________________________<br>
> > > Openid-specs-ab mailing list<br>
> > > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> > ><br>
> > <a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$</a><br>
> ><br>
> ><br>
> > On Wed, Aug 03, 2022 at 10:36:27AM -0400, Brock Allen via Openid-specs-ab<br>
> > wrote:<br>
> > > FWIW, we've used acr_values with a formatted value "idp:name_of_idp"<br>
> > approach.<br>
> > ><br>
> > > Similarly we also have used acr_values to pass tenant requirements with<br>
> > a formatted "tenant:name_of_tenant" for multi-tenant OP/AS scenarios.<br>
> > ><br>
> > ><br>
> > > -Brock<br>
> > > On 8/3/2022 10:32:09 AM, George Fletcher via Openid-specs-ab <<br>
> > <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> > > So it seems that we have many implementations of this concept. I think<br>
> > what I'm looking for is whether we should try and standardize a parameter<br>
> > for this use case, or just leave each domain to define their own way to<br>
> > enable this functionality.<br>
> > ><br>
> > > Thanks,<br>
> > > George<br>
> > ><br>
> > > On Wed, Aug 3, 2022 at 10:22 AM Marcus Hardt via Openid-specs-ab <<br>
> > <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>]><br>
> > wrote:<br>
> > ><br>
> > > Hi There,<br>
> > ><br>
> > > we've gone through this exercise within the AARC project. The scenario is<br>
> > > slightly more complex (we have this proxy architecture, and we're<br>
> > > protocol-agnostic-enough so that's also implementable in SAML), but I<br>
> > > think your use-case is fully covered in AARC-G061 [1].<br>
> > ><br>
> > > [1]<br>
> > <a href="https://urldefense.com/v3/__https://aarc-community.org/guidelines/aarc-g061/__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGWHgjLyk$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://aarc-community.org/guidelines/aarc-g061/__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGWHgjLyk$</a><br>
> > [<br>
> > <a href="https://urldefense.com/v3/__https://aarc-community.org/guidelines/aarc-g061/__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGWHgjLyk$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://aarc-community.org/guidelines/aarc-g061/__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGWHgjLyk$</a><br>
> > ]<br>
> > ><br>
> > ><br>
> > > The longer part of the story is, that we originally had the 'idphint'<br>
> > > parameter, which was too loosely defined. Hence we defined it as<br>
> > > 'aarc_idp_hint'.<br>
> > ><br>
> > > Essentially, it is a single-values url-encoded StringOrURI.<br>
> > ><br>
> > > The actual value is not specified, but I think it is generally assumed to<br>
> > > refer to either an 'iss' or in SAML to an 'entityID'.<br>
> > ><br>
> > ><br>
> > > If this aarc recommendation is not enough or too much from your<br>
> > > perspective, I think the original authors could be motivated to<br>
> > > participate in the discussion here.<br>
> > ><br>
> > > Best,<br>
> > > Marcus.<br>
> > ><br>
> > ><br>
> > > On 02. Aug 2022 11:22, George Fletcher wrote:<br>
> > > > Hi,<br>
> > > ><br>
> > > > I know I've mentioned this in the past and wanted to bring it up<br>
> > again. If<br>
> > > > an OpenID Provider allows for federation with multiple IDPs, there are<br>
> > > > times the client wants to "tell" the OP which of those federated IDPs<br>
> > to<br>
> > > > use.<br>
> > > ><br>
> > > > In a social login context, this can allow the client to specifically<br>
> > tell<br>
> > > > the OP to use Facebook for authenticating this user. However, this<br>
> > pattern<br>
> > > > is used in many other contexts.<br>
> > > ><br>
> > > > Any interest in writing a very small spec to enable an 'idp_hint'<br>
> > parameter<br>
> > > > that can be passed as part of the /authorization request? I suppose<br>
> > this<br>
> > > > could also go to the IETF as it's not specific to ODIC.<br>
> > > ><br>
> > > > Thoughts?<br>
> > > ><br>
> > > > Thanks,<br>
> > > > George<br>
> > > ><br>
> > > > ______________________________________________________________________<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > The information contained in this e-mail is confidential and/or<br>
> > proprietary to Capital One and/or its affiliates and may only be used<br>
> > solely in performance of work or services for Capital One. The information<br>
> > transmitted herewith is intended only for use by the individual or entity<br>
> > to which it is addressed. If the reader of this message is not the intended<br>
> > recipient, you are hereby notified that any review, retransmission,<br>
> > dissemination, distribution, copying or other use of, or taking of any<br>
> > action in reliance upon this information is strictly prohibited. If you<br>
> > have received this communication in error, please contact the sender and<br>
> > delete the material from your computer.<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > -------------- next part --------------<br>
> > > > An HTML attachment was scrubbed...<br>
> > > > URL: <<br>
> > <a href="https://urldefense.com/v3/__http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/74656401/attachment.html__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGrl20idE$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/74656401/attachment.html__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGrl20idE$</a><br>
> > [<br>
> > <a href="https://urldefense.com/v3/__http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/74656401/attachment.html__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGrl20idE$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/74656401/attachment.html__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGrl20idE$</a><br>
> > ]><br>
> > > ><br>
> > ><br>
> > > --<br>
> > > Marcus.<br>
> > > _______________________________________________<br>
> > > Openid-specs-ab mailing list<br>
> > > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a> [mailto:<br>
> > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>]<br>
> > ><br>
> > <a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$</a><br>
> > [<br>
> > <a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$</a><br>
> > ]<br>
> > ><br>
> > ><br>
> > ><br>
> > > The information contained in this e-mail is confidential and/or<br>
> > proprietary to Capital One and/or its affiliates and may only be used<br>
> > solely in performance of work or services for Capital One. The information<br>
> > transmitted herewith is intended only for use by the individual or entity<br>
> > to which it is addressed. If the reader of this message is not the intended<br>
> > recipient, you are hereby notified that any review, retransmission,<br>
> > dissemination, distribution, copying or other use of, or taking of any<br>
> > action in reliance upon this information is strictly prohibited. If you<br>
> > have received this communication in error, please contact the sender and<br>
> > delete the material from your computer.<br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________ Openid-specs-ab mailing<br>
> > list <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> > <a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$</a><br>
> ><br>
> > > _______________________________________________<br>
> > > Openid-specs-ab mailing list<br>
> > > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> > ><br>
> > <a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Nikhef Room 1.14<br>
> > Science Park 110 Tel. +31-6-4681 2202<br>
> > 1098 XG Amsterdam Fax +31-20-592 5155<br>
> > The Netherlands Email <a href="mailto:msalle@nikhef.nl" target="_blank">msalle@nikhef.nl</a><br>
> > __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..<br>
> > _______________________________________________<br>
> > Openid-specs-ab mailing list<br>
> > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> ><br>
> > <a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Oj3VUBqyffotiKGsFrU1lk_FJ6atKlv6XCUlnGrHZb8NJ8k1DiR5zu6Qm3obwXx-_bZBdAk92jPR2VNf8lz9iKZeAEru8pmGeNKlHA0$</a><br>
> ><br>
> <br>
> ______________________________________________________________________<br>
> <br>
> <br>
> <br>
> 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.<br>
> <br>
> <br>
> <br>
<br>
-- <br>
Nikhef Room 1.14<br>
Science Park 110 Tel. +31-6-4681 2202<br>
1098 XG Amsterdam Fax +31-20-592 5155<br>
The Netherlands Email <a href="mailto:msalle@nikhef.nl" target="_blank">msalle@nikhef.nl</a><br>
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>