[Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Tom Jones thomasclinganjones at gmail.com
Tue Nov 27 23:15:35 UTC 2018


I am headed to a w3c meeting that will talk about DIDs for the future. I
would like to understand if the self-issued ID requires (or should require)
some sort of (semi) permanent URL on the internet. (including on a
block-chain, for example.)  Without that i cannot understand what a
self-issued ID might even mean.

Peace ..tom


On Tue, Nov 27, 2018 at 3:06 PM Nat Sakimura via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Self Issued OP is described in Chapter 7 of the OpenID Connect Core 1.0.
> It lives on a local machine, typically a phone. Even if it did provide an
> authorization code to the client, the client cannot establish a direct
> connection to the local machine (phone) as it is not addressable.
> Therefore, a token endpoint cannot be provided unless it is coupled with
> some kind of cloud-based service, which would negate some of the very
> reason for having the Self-issued OP. In other words, only the viable
> communication channel between the SIOP and the client is the front channel.
> The situation could be true to other "wallet" type of implementations.
>
> This is one of the exotic features of OpenID Connect that never got a
> traction but it is getting a renewed interest as "Self-sovereign Identity"
> gained some interest.
>
>
>
> On Wed, Nov 28, 2018 at 6:03 AM Torsten Lodderstedt <
> torsten at lodderstedt.net> wrote:
>
>> I still don’t understand why the use case must be solved using a flow
>> issuing something in the front channel.
>>
>> I would also like to take a closer look. Can you or Nat provide pointers
>> to existing implementations?
>>
>> > Am 27.11.2018 um 21:36 schrieb John Bradley <ve7jtb at ve7jtb.com>:
>> >
>> > I understand that, but hat is Nat's concern as I understand it.
>> >
>> > When we say no implicit people, have a problem because implicit is
>> imprecise.
>> >
>> > We are saying no AT returned in the response from the authorization
>> endpoint.
>> >
>> > Nat points out that id_token may contain AT for the self issued client.
>> >
>> > So unless we say that is OK if the AT are sender constrained we wind up
>> implying that a OpenID profile of OAuth is in violation of the BCP.
>> >
>> > I am just trying to make sure everyone is on the same page with why Nat
>> was -1.
>> >
>> > It really has nothing to do with the SPA use case.
>> >
>> > John B.
>> >
>> >> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>> >> Hi John,
>> >>
>> >> as you said, self issued IDPs (
>> https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are
>> supposed to provide the response type „id_token“ only. I don’t think the
>> proposal being discussed here is related to this OIDC mode.
>> >>
>> >> best regards,
>> >> Torsten.
>> >>
>> >>> Am 27.11.2018 um 20:54 schrieb John Bradley <ve7jtb at ve7jtb.com>:
>> >>>
>> >>> I talked to Nat about this a bit today.
>> >>>
>> >>> The thing he is concerned about is mostly around the self issued IDP
>> that doesn't have a token endpoint(atleast not easaly).
>> >>>
>> >>> The main use case for that is the id_token response type where claims
>> are retuned in the id_token.
>> >>>
>> >>> Because it is fragment encoded some people call that implicit.   That
>> is not what we are trying to stop.
>> >>>
>> >>> In some cases in that flow there may be distributed claims returned
>> with access Token inside the id_token.    I think most people would agree
>> that those should be pop or sender constrained tokens.
>> >>>
>> >>> In the case of self issued the RP would be a server and could do
>> sender constrained via some mechinisim that is yet to be defined.
>> >>>
>> >>> So if someone wanted to return a access token in a id_token to do
>> distributed claims I don't think we have a problem with that as long as the
>> token is protected by being sender constrained in some reasonable way.
>> >>>
>> >>> This is a touch hypothetical from the basic OAuth perspective, so I
>> don't know how deep we want to go into it.
>> >>>
>> >>> I think the point is not to accidently prohibit something that could
>> be done in future.
>> >>>
>> >>> I also think we should not conflate confidential clients that can
>> authenticate to the token endpoint with sender constrained/PoP clients that
>> can deal with bound tokens.   Yes both have keys but it is better to
>> describe them separately.
>> >>>
>> >>> John B.
>> >>>
>> >>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab
>> <openid-specs-ab at lists.openid.net wrote:
>> >>> Hi Nat,
>> >>>
>> >>> I understand you are saying your draft could provide clients with an
>> application level mechanism to sender constrain access tokens. That’s great!
>> >>>
>> >>> But I don’t see a binding to response type „token id_token“. Why do
>> you want to expose the tokens via the URL to attackers?
>> >>>
>> >>> You could easily use your mechanism with code. That would also give
>> you the chance to really authenticate the confidential client before you
>> issue the token.
>> >>>
>> >>> kind regards,
>> >>> Torsten.
>> >>>
>> >>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <sakimura at gmail.com>:
>> >>>>
>> >>>> I am not talking about SPA.
>> >>>> The client is a regular confidential client that is running on a
>> server.
>> >>>>
>> >>>> Best,
>> >>>>
>> >>>> Nat Sakimura
>> >>>>
>> >>>>
>> >>>> 2018年11月27日(火) 16:55 Jim Manico <jim at manicode.com>:
>> >>>> Nat,
>> >>>>
>> >>>> How is proof of possession established in a modern web browser in
>> the implicit flow?
>> >>>>
>> >>>> My understanding is that token binding was removed from Chrome
>> recently effectively killing browser-based PoP tokens.
>> >>>>
>> >>>>
>> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>> >>>>
>> >>>> Am I missing something?
>> >>>>
>> >>>> Aloha, Jim
>> >>>>
>> >>>>
>> >>>>
>> >>>>> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>> >>>>> I am actually -1.
>> >>>>>
>> >>>>> +1 for public client and the tokens that are not sender/key
>> constrained.
>> >>>>>
>> >>>>> Just not being used right now does not mean that it is not useful..
>> In fact, I see it coming.
>> >>>>> Implicit (well, Hybrid “token id_token” really) is very useful in
>> certain cases.
>> >>>>> Specifically, when the client is confidential (based on public key
>> pair), and uses sender constrained (key-constrained) token such as the one
>> explained in
>> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it
>> is very useful.
>> >>>>> (Key-constrained token is the remaining portion of this draft that
>> did not get incorporated in the MTLS draft. )
>> >>>>> In fact it is the only viable method for Self-Issued OpenID
>> Provider.
>> >>>>>
>> >>>>> So, the text is generally good but it needs to be constrained like
>> “Unless the client is confidential and the access token issued is key
>> constrained, ... “
>> >>>>>
>> >>>>> Best,
>> >>>>>
>> >>>>> Nat Sakimura
>> >>>>>
>> >>>>>
>> >>>>> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <vladimir at connect2id.com>:
>> >>>>> +1 to recommend the deprecation of implicit.
>> >>>>>
>> >>>>> I don't see a compelling reason to keep implicit when there is an
>> >>>>> established alternative that is more secure.
>> >>>>>
>> >>>>> Our duty as WG is to give developers the best and most sensible
>> practice.
>> >>>>>
>> >>>>> CORS adoption is currently at 94% according to
>> >>>>> https://caniuse.com/#feat=cors
>> >>>>>
>> >>>>> Vladimir
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OAuth mailing list
>> >>>>> OAuth at ietf.org
>> >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>> --
>> >>>>> Nat Sakimura (=nat)
>> >>>>> Chairman, OpenID Foundation
>> >>>>> http://nat..sakimura.org/
>> >>>>> @_nat_en
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OAuth mailing list
>> >>>>>
>> >>>>> OAuth at ietf.org
>> >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>> --
>> >>>> Jim Manico
>> >>>> Manicode Security
>> >>>>
>> >>>> https://www.manicode.com
>> >>>> --
>> >>>> Nat Sakimura (=nat)
>> >>>> Chairman, OpenID Foundation
>> >>>> http://nat.sakimura.org/
>> >>>> @_nat_en
>> >>>> _______________________________________________
>> >>>> OAuth mailing list
>> >>>> OAuth at ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>> _______________________________________________
>> >>> Openid-specs-ab mailing list
>> >>> Openid-specs-ab at lists.openid.net
>> >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20181127/bbf732b3/attachment.html>


More information about the Openid-specs-ab mailing list