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

[Marius Scurtescu]

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
>
> 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/87ec6c97/attachment.html>