[Openid-specs-risc] Dependence on RFC6750 conflicts with other OIDF groups

Marius Scurtescu mscurtescu at google.com
Thu Apr 19 05:36:43 UTC 2018


Yes, I will be there tomorrow. Good idea.

Marius

On Wed, Apr 18, 2018 at 9:27 PM, Hardt, Dick <dick at amazon.com> wrote:

> I won’t be there Friday. We could chat about it tomorrow if you are at the
> MS event.
>
>
>
> On 4/18/18, 2:31 PM, someone claiming to be "Marius Scurtescu" <
> mscurtescu at google.com> wrote:
>
>
>
> Let's add this as an agenda item for the face-to-face on Friday.
>
>
> Marius
>
>
>
> On Wed, Apr 18, 2018 at 10:41 AM, Skyberg, David <
> David.Skyberg at capitalone.com> wrote:
>
> To what degree does at least the start of a trust framework need to be
> assumed before normative statements about OAuth 2 can be spec’d?  Ie,
>
>
>
> Cheers,
>
> =D=
>
>
>
> *From: *Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on
> behalf of "Hardt, Dick via Openid-specs-risc" <openid-specs-risc at lists.
> openid.net>
> *Reply-To: *"Hardt, Dick" <dick at amazon.com>
> *Date: *Tuesday, April 17, 2018 at 10:43 PM
> *To: *Marius Scurtescu <mscurtescu at google.com>
> *Cc: *Dick Hardt via Openid-specs-risc <openid-specs-risc at lists.openid.net
> >
> *Subject: *Re: [Openid-specs-risc] Dependence on RFC6750 conflicts with
> other OIDF groups
>
>
>
> RFC 6749 says how to obtain a token. 6750 is how to present it, which is
> what is required to make the API call. Specifying 6750 lets implement its
> know how calls will be made, and that they are like most OAuth based calls,
> rather than using mutual TLS or basic auth.
>
>
>
> I believe we are talking RISC on this list.
>
> -- Dick
>
>
> On Apr 17, 2018, at 10:05 PM, Marius Scurtescu <mscurtescu at google.com>
> wrote:
>
> Well, that was my point when I initially made OAuth 2 a requirement for
> the RISC Profile. Based on Phil's comments, you suggested to loosen that up
> and only require a bearer token, with that we already lost interop, I don't
> see a problem with loosening further.
>
>
>
> We have to decide what is the charter of RISC and if RISC cannot be
> specific about OAuth 2 then we need some other profile that anchors
> everything in OAuth 2 (or maybe in OIDC). All implementations I am aware of
> are anchored in OAuth 2 (access tokens, client ids, etc).
>
>
>
> I agree with Phil that in general secevent should allow other
> authorization methods, but not sure if RISC should also allow that, and
> where would things become concrete.
>
>
>
>
> Marius
>
>
>
> On Tue, Apr 17, 2018 at 8:34 PM, Hardt, Dick <dick at amazon.com> wrote:
>
> Marius: what is the point if it is non-normative?  There is little value
> in referencing OAuth unless you are going to specify something that
> promotes interop.
>
>
>
> On 4/17/18, 3:51 PM, someone claiming to be "Marius Scurtescu" <
> mscurtescu at google.com> wrote:
>
>
>
> Phil,
>
>
>
> I think suggesting in a non-normative way the use of OAuth Bearer tokens,
> or even OAuth 2 access tokens makes sense.
>
>
>
> Dependence on RFC7519 on the other hand does not work. Most OAuth 2
> implementations are not using JWT as token format. Maybe I misunderstand.
>
>
>
> Are you OK with changing the OAuth Bearer token reference to a
> non-normative one?
>
>
> Marius
>
>
>
> On Fri, Apr 6, 2018 at 11:16 AM, Hardt, Dick via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
> FAPI and iGov are standards, not an organization. Is there a reason why an
> organization that is using FAPI or iGov cannot use bearer tokens?
>
>
>
> On 4/6/18, 9:59 AM, someone claiming to be "Phil Hunt" <
> phil.hunt at oracle.com> wrote:
>
>
>
> I cited FAPI and iGov as examples of cases that cannot use bearer tokens
> as defined by RFC6750.
>
>
>
> I agree that one advantage of 6750 is it does not mandate JWT.
>
>
>
> This is why I stated mandated JWT would be a compromise.  We discussed in
> the past that the compromise was that JWT’s could be manually generated in
> the absence of OAuth token servers.
>
>
>
> Phil
>
>
>
> Oracle Corporation, Identity Cloud Services Architect
>
> @independentid
>
> www.independentid.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMF-g&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=dpcjJJ2Kw0U8wmc6cf3KuxlNsnLbNMMD1_Km0w8FXpaxakm_XM-PyeZX-dTBRjdF&m=-5XUsGZRHvOkiQ57kCniMx69H5kleL0UNRmHaefxVFU&s=mP1-5yl6fRDNq99AkR7HkbzjYenemfV5w9sRiUoH6wA&e=>
>
> phil.hunt at oracle.com
>
>
>
> On Apr 6, 2018, at 9:51 AM, Hardt, Dick <dick at amazon.com> wrote:
>
>
>
> An OAuth Bearer token != a JWT. Dictating JWT would force deployments that
> have their own proprietary tokens to adopt JWT, for zero benefit as the the
> token issuer and token receiver are the same entity, so there is no
> requirement for interop.
>
>
>
> While there are numerous ways to authenticate, picking one widely deployed
> mechanism simplifies adoption.
>
>
>
> It is unclear why a bearer token for RISC would be in conflict with
> someone that has used FAPI or iGov. Just because they use a POP for
> authentication of the user, does not mean they can’t use a bearer token for
> the RISC control plane.
>
>
>
> Do you have an example of someone that wants to deploy RISC where 6750
> would be problematic?
>
>
>
> /Dick
>
>
>
> On 4/6/18, 9:22 AM, someone claiming to be "Openid-specs-risc on behalf of
> Phil Hunt via Openid-specs-risc" <openid-specs-risc-bounces@
> lists.openid.net on behalf of openid-specs-risc at lists.openid.net> wrote:
>
>
>
> The dependence on RFC6750 (OAuth bearer tokens) is a concern because it
> limits security agility.
>
>
>
> I have stated, my preference is for any HTTP security mechanism to be
> permissible because implicit federation entities are not always using OAuth
> based infrastructure - yet many do have sophisticated IDM and security
> systems.
>
>
>
> That concern aside, there are other OIDF working groups (FAPI and iGov)
> that are mandating the use of bound or proof-of-possesion tokens. These
> groups would be unable to use RISC’s proposed bearer token security model
> as they only accept token binding and mutual tls bound tokens.
>
>
>
> As a compromise, I suggest the dependence be made on RFC7519 (JWT tokens)
> instead of RFC6750.  It would be reasonable to suggest, in a non-normative
> way the use of OAuth Bearer tokens as an example solution for RISC.
>
>
>
> Phil
>
>
>
> Oracle Corporation, Identity Cloud Services Architect
>
> @independentid
>
> www.independentid.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tMyrA88xBOR5PoGwZna-QzVmvSJosoix0WzQ3HLSEEc&s=eTcI2trRAeFmRS_r61nkuVD4J8aSzzOaiUYETFMHft8&e=>
>
> phil.hunt at oracle.com
>
>
>
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwMF-g&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=dpcjJJ2Kw0U8wmc6cf3KuxlNsnLbNMMD1_Km0w8FXpaxakm_XM-PyeZX-dTBRjdF&m=-5XUsGZRHvOkiQ57kCniMx69H5kleL0UNRmHaefxVFU&s=G0YS0RLGPfAikM2WdzaC9Uh4usQTsvzMC3_mCTvlKg0&e=>
>
>
>
>
>
>
> ------------------------------
>
> 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-risc/attachments/20180418/c825a41a/attachment-0001.html>


More information about the Openid-specs-risc mailing list