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

Marius Scurtescu mscurtescu at google.com
Tue Apr 17 22:51:07 UTC 2018


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
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180417/e1257c44/attachment.html>


More information about the Openid-specs-risc mailing list