[Openid-specs-ab] [External Sender] Re: IDP Hint for /authorization requests
Marcus Hardt
hardt at kit.edu
Tue Aug 9 08:28:49 UTC 2022
When writing the AARC-G061 document about the aarc_idp_hint, we first
collected use-cases. All the four cases have this in common:
- We have a large number of OPs (and SAML IdPs as a matter of fact), one
of which the user chooses to authenticate by entering some credentials
- We have an OP, which needs to send the user to the right IdP.
- We have an RP, which - in the sense of the IdP hint - has a good idea
which IdP the user should be sent to.
There may be reasons for the OP not to follow the hint. This is why it's
only a hint and not an order. Therefore a specification for an idp_hint
should stick to defining the following (putting my opinion in brackets)
- how the hint is conveyed (idp_hint)
- how the content is constructed (urlencode)
- how many values to pass (one)
One could (maybe should) also provide guidance of what may be expected
inside the hint value. I think there are two options:
a) leave it open to the RP/OP relation.
b) define it to be an 'iss' (or SAML entityID) to which the OP may the
if e.g. the trust relations allow that.
If the RP messes things up (because the user travelled from one continent
to another) this is bad, but outside the spec.
If the user email is user at domain2.com, but the RP is convinced it is
better to send her to domain1.com, well, then there be good reasons for
that - all of them unrelated to the spec :)
Best,
Marcus.
On 08. Aug 2022 11:10, Vittorio Bertocci via Openid-specs-ab wrote:
> 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 domain1.com, the fact that you want that for
> user at domain2.com (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.
> 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 :)).
> 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.
>
> On Mon, Aug 8, 2022 at 6:22 AM Mischa Salle via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> >
> > This message originated outside your organization.
> >
> >
> > 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
> >
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
--
Marcus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5354 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220809/ea8b6578/attachment.p7s>
More information about the Openid-specs-ab
mailing list