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

Tom Jones thomasclinganjones at gmail.com
Wed Nov 28 00:14:11 UTC 2018


I see, so then the self-issued ID is device-locked? it sounds more like a
device ID than a user ID.  Which is useful, but not too helpful in a
multiple device world. The screen i am using right now has 3 devices
driving it in one form or another. Is there any way that a self-issued ID
of this form can be made useful in today's world?  BTW - i like the idea of
URN's rather than URL's, but some resolver capability seems to be a
requirement?
Peace ..tom


On Tue, Nov 27, 2018 at 3:50 PM n-sakimura <n-sakimura at nri.co.jp> wrote:

> Tom,
>
>
>
> It is good to hear that you will be there.
>
> I understand John will also be there.
>
>
>
> To your question, self-issued ID does not require a (semi-)permanent URL
> as the user’s identifier, as it is always “localhost”.
>
> The identifier is derived as the hash of the public key that was generated
> by the Self-issued OP.
>
> If your question was “URI”, then yes. Its issuer is always
> https://self-issued.me and there is a `sub` for that identity, so
> synthesized URI for the user would be something like
> https://self-issued.me/{sub} where {sub} represents the value of the
> `sub` claim. `sub` claim value is defined as follows:
>
>
>
> sub (subject) Claim value is the base64url encoded representation of the
> thumbprint of the key in the sub_jwk Claim. This thumbprint value is
> computed as the SHA-256 hash of the octets of the UTF-8 representation of a
> JWK constructed containing only the REQUIRED members to represent the key,
> with the member names sorted into lexicographic order, and with no white
> space or line breaks. For instance, when the kty value is RSA, the member
> names e, kty, and n are the ones present in the constructed JWK used in
> the thumbprint computation and appear in that order; when the kty value
> is EC, the member names crv, kty, x, and y are present in that order.
> Note that this thumbprint calculation is the same as that defined in the
> JWK Thumbprint *[JWK.Thumbprint]**Jones, M., “JSON Web Key (JWK)
> Thumbprint,” July 2014.*
> <https://openid.net/specs/openid-connect-core-1_0.html#JWK.Thumbprint>
>  specification.
>
>
>
> So, yes. The string https://self-issued.me/{sub} is probabilistically
> unique and “persistent” (better to phrase it as ‘never re-assigned’).
>
>
>
> The reason it is not a “URL” is that you cannot reach it. However, It is a
> “URI”.
>
>
>
> Cheers,
>
>
>
>
>
> Nat Sakimura <n-sakimura at nri.co.jp>
>
>
>
> PLEASE READ :This e-mail is confidential and intended for the named
> recipient only. If you are not an intended recipient, please notify the
> sender and delete this e-mail.
>
>
>
>
>
>
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
> Behalf Of *Tom Jones via Openid-specs-ab
> *Sent:* Wednesday, November 28, 2018 8:16 AM
> *To:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *Cc:* Tom Jones <thomasclinganjones at gmail.com>; oauth at ietf.org;
> jim at manicode.com
> *Subject:* Re: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics --
> Recommend authorization code instead of implicit
>
>
>
> 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/de0ee164/attachment-0001.html>


More information about the Openid-specs-ab mailing list