Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

2018-12-02 Thread Rob Otto
Apologies if I'm being dim (it wouldn't be the first time!) but how, in
this scenario, do we identify the browser client and authenticate it to the
backend, to associate it with the correct token(s)?

Cheers (and really interesting discussion so far)

Rob

On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt 
wrote:

> the UI is rendered in the frontend, UI control flow is in the frontend.
> just a different cut through the web app’s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot of
> sense to me. The backend can aggregate and optimize access to the
> underlying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley :
>
> How is that different from a regular server client with a web interface if
> the backed is doing the API calls to the RS?
>
>
> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>
> I forgot to mention another (architectural) option: split an application
> into frontend provided by JS in the browser and a backend, which takes care
> of the business logic and handles tokens and API access. Replay detection
> at the interface between SPA and backend can utilize standard web
> techniques (see OWASP). The backend in turn can use mTLS for sender
> constraining.
>
> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
> tors...@lodderstedt.net>:
>
> IMHO the best mechanism at hand currently to cope with token
> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
> detection) and issue short living and privilege restricted access tokens.
>
> Sender constrained access tokens in SPAs need adoption of token binding or
> alternative mechanism. mtls could potentially work in deployments with
> automated cert rollout but browser UX and interplay with fetch needs some
> work. We potentially must consider to warm up application level PoP
> mechanisms in conjunction with web crypto. Another path to be evaluated
> could be web auth.
>
> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
> hannes.tschofe...@arm.com>:
>
> I share the concern Brian has, which is also the conclusion I came up with
> in my other email sent a few minutes ago.
>
>
>
> *From:* OAuth  *On Behalf Of *Brian Campbell
> *Sent:* Friday, November 30, 2018 11:43 PM
> *To:* Torsten Lodderstedt 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>
>
>
>
>
> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which is still some time off)?
>
> Sure. That’s why the Security BCP recommends use of TLS-based methods for
> sender constraining access tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2).
> Token Binding for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
> <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>) as well
> as Mutual TLS for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options
> available.
>
>
>
> Unfortunately even when using the token endpoint, for SPA / in-browser
> client applications, the potential mechanisms for sender/key-constraining
> access tokens don't work very well or maybe don't work at all. So I don't
> know that the recommendation is very realistic.
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> ht

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-03-26 Thread Rob Otto
ts.pptx
>>>>>
>>>>> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>>>>) - got early feedback from Filip Skokan on it. Thx Filip!
>>>>>- The presentation was followed up by 1.5 hours of unconference
>>>>>discussion, which was incredibly valuable to get tight-loop feedback 
>>>>> and
>>>>>incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>>>>>Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all
>>>>>there and contributed generously to the discussion. Thank you!!!
>>>>>Note: if you were at OSW2019, participated in the discussion and
>>>>>didn't get credited in the draft, my apologies: please send me a note 
>>>>> and
>>>>>I'll make things right at the next update.
>>>>>- On my flight back I did my best to incorporate all the ideas and
>>>>>feedback in a draft, which will be discussed at IETF104 tomorrow. 
>>>>> Rifaat,
>>>>>Hannes and above all Brian were all super helpful in negotiating the
>>>>>mysterious syntax of the RFC format and submission process.
>>>>>
>>>>> I was blown away by the availability, involvement and willingness to
>>>>> invest time to get things right that everyone demonstrated in the process.
>>>>> This is an amazing community.
>>>>> V.
>>>>> ___
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>> ___
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> ___
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>>
>>>> --
>>>> hans.zandb...@zmartzone.eu
>>>> ZmartZone IAM - www.zmartzone.eu
>>>>
>>>>
>>>
>>> --
>>> hans.zandb...@zmartzone.eu
>>> ZmartZone IAM - www.zmartzone.eu
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] MTLS and Native apps Best practices

2019-05-03 Thread Rob Otto
Are you hoping to use the key to authenticate the user, or the OAuth
client? If it's the latter, then you don't need to use MTLS to the
authorisation endpoint. If it's the former, I'd argue that you would
certainly need to include your public key in an X509 cert and *somehow*
make it available to the system browser.

On Fri, 3 May 2019 at 08:07, Phil Hunt  wrote:

> Yes. I was more wondering if the app can invoke the system embedded view
> using its own key pair to ensure protected authen.
>
> Eg. If the authorization endpoint is set to require mutual tls, can the
> system view use the app’s keys since the app is invoking it?
>
> Or, would there have to be a user x..509 cert embedded in the browser
> store?
>
> I agree browser based apps is another matter.
>
> Phil
>
> On May 2, 2019, at 11:27 PM, Torsten Lodderstedt 
> wrote:
>
> Hi Phil,
>
> since mTLS is used at the tokens endpoint, native apps can definitely use
> their own key  pair. I would asunder such an app to act as public client,
> but mTLS would allow such an app to bind its key pair with the token
> request to the issued tokens.
>
> Apps running in the browser is a separate topic. There are potential
> issues with using the certs in the browser. That’s why work towards an
> application level PoP mechanism has been started - DPoP.
>
> best regards,
> Torsten.
>
> Am 02.05.2019 um 20:41 schrieb Phil Hunt :
>
> I was wondering if anyone had any recommended MTLS best practices for
> mobile apps and native browsers.
>
> Considering Section 6 of RFC8252…
>
>After constructing the authorization request URI, the app uses
>platform-specific APIs to open the URI in an external user-agent.
>Typically, the external user-agent used is the default browser, that
>is, the application configured for handling "http" and "https" scheme
>URIs on the system; however, different browser selection criteria and
>other categories of external user-agents MAY be used.
>
>
> What choices do developers have to ensure the authorization (and
> subsequent user authentication) occur over MTLS? Can the app provide its
> own key for MTLS or can it ask that an embedded X.509 cert be used
> (assuming one is available)?
>
> Are there any platform issues or best practices?
>
> Phil Hunt | Cloud Security and Identity Architect
> Oracle Corporation, Oracle Cloud Infrastructure
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
robo...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo]
<https://plus.google.com/u/0/114266977739397708540> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.pingidentity.com/content/ping/en/lp/d/p14e-trial.html>
<https://www.pingidentity.com/en/lp/d/p14e-trial.html?utm_source=Email&utm_medium=p14e-trial-sso-mfa-emailsig&utm_campaign=p14e-trial-sso-mfa-emailsig>
<https://www.pingidentity.com/en/lp/d/p14e-trial.html?utm_source=Email&utm_medium=p14e-trial-sso-mfa-emailsig&utm_campaign=p14e-trial-sso-mfa-emailsig>
<https://developer.pingidentity.com/en/signup.html>
<https://developer.pingidentity.com/en/signup.html>
<https://developer.pingidentity.com/en/signup.html>
<https://developer.pingidentity.com/en/signup.html?utm_source=email&utm_medium=P14C-Trial-Email&utm_campaign=P14C-Trial-Email&utm_content=link>
<https://developer.pingidentity.com/en/signup.html?utm_source=email&utm_medium=P14C-Trial-Email&utm_campaign=P14C-Trial-Email&utm_content=link>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] Question regarding RFC 8628

2019-11-18 Thread Rob Otto
Salut Hervé

I wonder if you have looked at all at the OpenID Connect Client-Initiated
BackChannel Authentication (CIBA) flow for this use case? Certainly the
feeling amongst the Open Banking community here in the UK is that  it might
be a better fit for decoupled authentication than the Device Authorisation
Grant. There is even a FAPi (Financial-Grade API) profile of CIBA that is
making its way through the standardisation process - and even has a working
conformance testing suite.

The other option, that could make life easier when it comes to the final
step you mention (switching back to the TPP app from the Bank app) is to
use an app-to-app redirect model under OIDC. Again this is a popular model
for same-device scenarios that's been implemented by many banks here in the
UK.

If you'd like more information on either of these approaches, I'm happy to
share.

Best regards
Rob



On Mon, 18 Nov 2019 at 08:24, Robache Hervé  wrote:

> Dear all
>
>
>
> We are considering using RFC8628 for a specific use case that is related
> to the version 2 of Payment Service Directive in Europe (PSD2).
>
>
>
> The purpose of the work is to provide a decoupled authentication flow for
> a payment Service User (PSU) aiming to grant access to a Third Party
> Provider (TPP) for his/her data hosted by a Bank.
>
> The sequence should be as followed:
>
> -  Nominal flow (as specified by the RFC)
>
> o   The TPP asks the PSU about the Bank identity
>
> o   The TPP posts a Device Access Token Request to the Bank
>
> o   The Bank sends back a Device Access Token response to the TPP
>
> o   The TPP starts to poll the bank for gaining the access token
>
> -  Derived flow
>
> o   The “verification_uri_complete” will not be displayed to the PSU but
> used as an [app link]/[universal link] on a smartphone in order to launch
> the bank’s app.
>
> o   The bank’s app authenticates the PSU and asks for consent confirmation
>
> -  Back to the nominal flow
>
> o   The TPP gets its access token
>
>
>
> Two questions have raised during the work
>
> -  As RFC8628 is supposed to work on separate devices, can the
> usage be extrapolated to separate apps on the same device (i.e. the PSU’s
> smartphone)?
>
> -  One issue of the derived flow is that, after authentication,
> the PSU is still facing the bank’s app
>
> o   We would like to go back to the TPP’s app as fluently as possible.
> The use of another [app link]/[universal link]could do the job is provided
> by the TPP. We consider adding this uri as an additional parameter to the
> “verification_uri_complete”.
>
> o   Is this compliant with RFC8628?
>
>
>
> Thanks in advance for your answers.
>
>
>
> Hervé Robache
>
>
> Ce message et toutes les pièces jointes sont établis à l'intention
> exclusive de ses destinataires et sont confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destiné,
> merci de le détruire ainsi que toute copie de votre système et d'en avertir
> immédiatement l'expéditeur.
> Toute lecture non autorisée, toute utilisation de ce message qui n'est pas
> conforme à sa destination, toute diffusion ou toute publication, totale ou
> partielle, est interdite.
> L'Internet ne permettant pas d'assurer l'intégrité de ce message
> électronique susceptible d'altération, STET décline toute responsabilité au
> titre de ce message dans l'hypothèse où il aurait été modifié, déformé ou
> falsifié.
> N'imprimez ce message que si nécessaire, pensez à l'environnement.
>
> This message and any attachments is intended solely for the intended
> addressees and is confidential.
> If you receive this message in error, or are not the intended
> recipient(s), please delete it and any copies from your systems and
> immediately notify the sender.
> Any unauthorized view, use that does not comply with its purpose,
> dissemination or disclosure, either whole or partial, is prohibited.
> Since the internet cannot guarantee the integrity of this message which
> may not be reliable, STET shall not be liable for the message if modified,
> changed or falsified.
> Do not print this message unless it is necessary, please consider the
> environment.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_

Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [3/3]

2019-11-19 Thread Rob Otto
" don't use the Implicit or Resource Owner Password Credentials  grant
types"

I cannot overstate how strongly I would support this recommendation in
particular!

Best regards
Rob


On Tue, 19 Nov 2019 at 10:07, Hans Zandbelt 
wrote:

> How about:
>
> - don't use the Implicit or Resource Owner Password Credentials  grant
> types
> - perform exact matching of redirect URIs and make then Client/AS specific
> - use PKCE
>
> Hans.
>
> On Tue, Nov 19, 2019 at 5:58 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>>
>>
>> > On 19. Nov 2019, at 17:10, Hans Zandbelt 
>> wrote:
>> >
>> >
>> >
>> > On Tue, Nov 19, 2019 at 10:38 AM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>> > Hi Hans,
>> >
>> > > On 18. Nov 2019, at 04:11, Hans Zandbelt 
>> wrote:
>> > >
>> > > Hi,
>> > >
>> > > Please find my feedback from page 21 onwards below.
>> > >
>> > > Hans.
>> > >
>> > > Overall I would argue there's room for a very concise guidance
>> section that says: do this, don't do that, without explanation, just as a
>> reference for developers; the current text provides in depth analysis but
>> that is perhaps not suitable for developers who just want to know what to
>> do (or not to do) and don't really care about the background/reasoning
>> >
>> > While section 4 gives the raw security threat analysis, we tried to
>> summarise the actionable guidance in section 3. What do you miss there?
>> >
>> > I'd rather see it even shorter and more concise, but I guess you're
>> right, it is there
>>
>> Do you want to suggest some text?
>>
>> >
>> > >
>> > > P21
>> > > first bullet
>> > > "the client has bound this data to this particular instance." ->
>> particular instance of what?
>> >
>> > This bullet refers to the note above.
>> >
>> > "Note: this check could also detect attempts to inject a code which
>> >had been obtained from another instance of the same client on another
>> >device, if certain conditions are fulfilled:"
>> >
>> > ok, I see
>> >
>> > >
>> > > 3rd paragraph:
>> > > "call to the tokens endpoint." -> "call to the token endpoint."
>> >
>> > Fixed
>> >
>> > >
>> > > last paragraph could forward point to the next section by adding
>> something like
>> > > "using one of the mechanisms described in the next section."
>> >
>> > Incorporated
>> >
>> > >
>> > > P22
>> > > 3rd paragraph:
>> > > is the token binding guidance still accurate? it seems to be
>> overestimating the adoption
>> >
>> > You mean this statement?
>> >
>> > "Token binding is
>> >   promising as a secure and convenient mechanism (due to its browser
>> >   integration).  As a challenge, it requires broad browser support
>> >   and use with native apps is still under discussion.”
>> >
>> > yeah, but after re-reading I guess this actually spells out the
>> adoption conditions, so it is fine
>> >
>> > Hans.
>> >
>> >
>> > Thanks,
>> > Torsten.
>> >
>> > >
>> > > --
>> > > hans.zandb...@zmartzone.eu
>> > > ZmartZone IAM - www.zmartzone.eu
>> > > ___
>> > > OAuth mailing list
>> > > OAuth@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>> >
>> > --
>> > hans.zandb...@zmartzone.eu
>> > ZmartZone IAM - www.zmartzone.eu
>>
>>
>
> --
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo]
<https://plus.google.com/u/0/114266977739397708540> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

2019-11-21 Thread Rob Otto
Hi everyone

I'd agree with this. I'm looking at DPOP as an alternative and
ultimately simpler way to accomplish what we can already do with MTLS-bound
Access Tokens, for use cases such as the ones we address in Open Banking;
these are API transactions that demand a high level of assurance and as
such we absolutely must have a mechanism to constrain those tokens to the
intended bearer. Requiring MTLS across the ecosystem, however, adds
significant overhead in terms of infrastructural complexity and is always
going to limit the extent to which such a model can scale.

DPOP, to me, appears to be a rather more elegant way of solving the same
problem, with the benefit of significantly reducing the complexity of (and
dependency on) the transport layer. I would not argue, however, that it is
meant to be a solution intended for ubiquitous adoption across all
OAuth-protected API traffic. Clients still need to manage private keys
under this model and my experience is that there is typically a steep
learning curve for developers to negotiate any time you introduce a
requirement to hold and use keys within  an application.

I guess I'm with Justin - let's look at DPOP as an alternative to
MTLS-bound tokens for high-assurance use cases, at least initially, without
trying to make it solve every problem.

Best regards
Rob


On Fri, 22 Nov 2019 at 07:24, Justin Richer  wrote:

> I’m going to +1 Dick and Annabelle’s question about the scope here. That
> was the one major thing that struck me during the DPoP discussions in
> Singapore yesterday: we don’t seem to agree on what DPoP is for. Some
> (including the authors, it seems) see it as a quick point-solution to a
> specific use case. Others see it as a general PoP mechanism.
>
> If it’s the former, then it should be explicitly tied to one specific set
> of things. If it’s the latter, then it needs to be expanded.
>
> I’ll repeat what I said at the mic line: My take is that we should
> explicitly narrow down DPoP so that it does exactly one thing and solves
> one narrow use case. And for a general solution? Let’s move that discussion
> into the next major revision of the protocol where we’ll have a bit more
> running room to figure things out.
>
>  — Justin
>
> On Nov 22, 2019, at 3:13 PM, Dick Hardt  wrote:
>
>
>
> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden 
> wrote:
>
>> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle 
>> wrote:
>>
>> There are key distribution challenges with that if you are doing
>> validation at the RS, but validation at the RS using either approach means
>> you’ve lost protection against replay by the RS. This brings us back to a
>> core question: what threats are in scope for DPoP, and in what contexts?
>>
>>
>> Agreed, but validation at the RS is premature optimisation in many cases..
>> And if you do need protection against that the client can even append a
>> confirmation key as a caveat and retrospectively upgrade a bearer token to
>> a pop token. They can even do transfer of ownership by creating copies of
>> the original token bound to other certificates/public keys.
>>
>
> While validation at the RS may be an optimization in many cases, it is
> still a requirement for deployments.
>
> I echo Annabelle's last question: what threats are in scope (and out of
> scope) for DPoP?
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo]
<https://plus.google.com/u/0/114266977739397708540> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confident

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

2019-11-22 Thread Rob Otto
Hi Torsten - thanks for the reply.

Responses in line.

Grüsse
Rob

On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt  wrote:

> Hi Rob,
>
> > On 22. Nov 2019, at 15:52, Rob Otto  40pingidentity@dmarc.ietf.org> wrote:
> >
> > Hi everyone
> >
> > I'd agree with this. I'm looking at DPOP as an alternative and
> ultimately simpler way to accomplish what we can already do with MTLS-bound
> Access Tokens, for use cases such as the ones we address in Open Banking;
> these are API transactions that demand a high level of assurance and as
> such we absolutely must have a mechanism to constrain those tokens to the
> intended bearer. Requiring MTLS across the ecosystem, however, adds
> significant overhead in terms of infrastructural complexity and is always
> going to limit the extent to which such a model can scale.
>
> I would like to unterstand why mTLS adds “significant overhead in terms of
> infrastructural complexity”. Can you please dig into details?
>

I guess it's mostly that every RS-endpoint (or what sits in front of it)
has to have a mechanism for accepting/terminating mTLS, managing roots of
trust, validating/OCSP, etc and then passing the certificates downstream as
headers. None of it is necessarily difficult or impossible to do in
isolation, but I meet many many people every week who simply don't know how
to do any of this stuff. And these are typically "network people", for want
of a better word. There are quite a few SaaS API management and edge
solutions out there that don't even support mTLS at all. You also have the
difficulty in handling a combination of MTLS and non-MTLS traffic to the
same endpoints. Again, it's possible to do, but far from straightforward.



>
> Our experience so far: It can be a headache to set up in a microservice
> architecture with TLS terminating proxies but once it runs it’s ok. On the
> other side, it’s easy to use for client developers and it combines client
> authentication and sender constraining nicely.
>

I do think its an elegant solution, don't get me wrong. It's just that
there are plenty of moving parts that you need to get right and that can be
a challenge, particularly in large, complex environments.



>
> >
> > DPOP, to me, appears to be a rather more elegant way of solving the same
> problem, with the benefit of significantly reducing the complexity of (and
> dependency on) the transport layer. I would not argue, however, that it is
> meant to be a solution intended for ubiquitous adoption across all
> OAuth-protected API traffic. Clients still need to manage private keys
> under this model and my experience is that there is typically a steep
> learning curve for developers to negotiate any time you introduce a
> requirement to hold and use keys within  an application.
>
> My experience is most developer don’t even get the URL right (in the
> signature and the value used on the receiving end). So the total cost of
> ownership is increased by numerous support inquiries.
>
I'll not comment, at the risk of offending developers :)

>
> best regards,
> Torsten.
>
> >
> > I guess I'm with Justin - let's look at DPOP as an alternative to
> MTLS-bound tokens for high-assurance use cases, at least initially, without
> trying to make it solve every problem.
> >
> > Best regards
> > Rob
> >
> >
> > On Fri, 22 Nov 2019 at 07:24, Justin Richer  wrote:
> > I’m going to +1 Dick and Annabelle’s question about the scope here. That
> was the one major thing that struck me during the DPoP discussions in
> Singapore yesterday: we don’t seem to agree on what DPoP is for. Some
> (including the authors, it seems) see it as a quick point-solution to a
> specific use case. Others see it as a general PoP mechanism.
> >
> > If it’s the former, then it should be explicitly tied to one specific
> set of things. If it’s the latter, then it needs to be expanded.
> >
> > I’ll repeat what I said at the mic line: My take is that we should
> explicitly narrow down DPoP so that it does exactly one thing and solves
> one narrow use case. And for a general solution? Let’s move that discussion
> into the next major revision of the protocol where we’ll have a bit more
> running room to figure things out..
> >
> >  — Justin
> >
> >> On Nov 22, 2019, at 3:13 PM, Dick Hardt  wrote:
> >>
> >>
> >>
> >> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden 
> wrote:
> >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
> >>> There are key distribution challenges with that if you are doing
> validation at the RS, but validation at the RS using eit

Re: [OAUTH-WG] Meeting Minutes

2019-12-16 Thread Rob Otto
I’d support adoption of both PAR and RAR.

On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle  wrote:

> +1 for a call for adoption on PAR.
>
>
>
> I’d also like to see one for RAR; while there are questions that need to
> be resolved, there seems to be strong interest in this work and adoption
> means we can have those discussions within the WG where they belong.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of Justin Richer <
> jric...@mit.edu>
> *Date: *Monday, December 16, 2019 at 12:36 PM
> *To: *Brian Campbell 
> *Cc: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Meeting Minutes
>
>
>
> +1 to this. My take away was that PAR was pretty clear for adoption right
> now, RAR had interest but more question/debate.
>
>
>
> FWIW I’m in favor of both of them.
>
>
>
>  — Justin
>
>
>
> On Dec 16, 2019, at 11:26 AM, Brian Campbell <
> bcampbell=40pingidentity@dmarc.ietf.org> wrote:
>
>
>
> With respect to the Pushed Authorization Requests (PAR) draft the minutes
> do capture an individual comment that it's a "no brainer to adopt this
> work" but as I recall there was also a hum to gauge the room's interest in
> adoption, which was largely in favor of such. Of course, one hum in
> Singapore isn't the final word but, following from that, I was
> hoping/expecting to see a call for adoption go out to the mailing list?
>
>
>
> On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
> Here are the meeting minutes from the Singapore IETF meeting:
>
> https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03
>
>
>
> Tony was our scribe. Thanks!
>
>
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

2020-01-06 Thread Rob Otto
I support adoption

On Mon, 6 Jan 2020 at 22:22, Jim Willeke  wrote:

> I support adoption.
> --
> -jim
> Jim Willeke
>
>
> On Mon, Jan 6, 2020 at 3:36 PM Dick Hardt  wrote:
>
>> I support adoption
>> ᐧ
>>
>> On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle > 40amazon@dmarc.ietf.org> wrote:
>>
>>> I support adoption.
>>>
>>>
>>>
>>> –
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>>
>>>
>>> *From: *OAuth  on behalf of John Bradley <
>>> ve7...@ve7jtb.com>
>>> *Date: *Monday, January 6, 2020 at 12:05 PM
>>> *To: *"oauth@ietf.org" 
>>> *Subject: *Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich
>>> Authorization Requests
>>>
>>>
>>>
>>> I support adoption
>>>
>>> On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:
>>>
>>> All,
>>>
>>>
>>>
>>> This is a call for adoption for the *OAuth 2.0 Rich Authorization
>>> Requests* document.
>>>
>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>>>
>>>
>>>
>>> Please, let us know if you support or object to the adoption of this
>>> document as a working group document by Jan 20th.
>>>
>>>
>>>
>>> Regards,
>>>
>>>  Rifaat & Hannes
>>>
>>>
>>>
>>>
>>>
>>> _______
>>>
>>> OAuth mailing list
>>>
>>> OAuth@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] Call for Adoption: DPoP

2020-03-17 Thread Rob Otto
I support adoption

Thank you
Rob Otto

On Tue, 17 Mar 2020 at 12:21, Rifaat Shekh-Yusef 
wrote:

> All,
>
> As per the conclusion of the PoP interim meeting, this is a call for
> adoption for the *OAuth 2.0 Demonstration of Proof-of-Possession at the
> Application Layer (DPoP)* document:
> https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/
>
> Please, let us know if you support or object to the adoption of this
> document as a working group document by March 31st.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://developer.pingidentity.com/en/signup.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

2020-03-17 Thread Rob Otto
ailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986126557&sdata=I5KDQT%2BdT0lapMOr71odsiCRrZ7csVZMuaYnMzsWwhM%3D&reserved=0>
>> > >>
>> > >> ___
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0>
>> > >
>> > > ___
>> > > OAuth mailing list
>> > > OAuth@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/oauth
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0>
>> >
>>
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986146548&sdata=%2B1PGj7U2CLMlh6HWf8BuGIvqtcGkz0hLMJYlktmkLc4%3D&reserved=0>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986156545&sdata=2lgFg7%2F%2BLZ%2FgoabHcpK1ggg1FgNaArMIUKojGxJ%2BdLk%3D&reserved=0>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://nam06.safelinks..protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=Ex9kDYE8r4E0Y2KxMdDpwtZVWdNrq1Uqm6eYFf1LcsI%3D&reserved=0>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=%2FEt7X7DH8psh0JPtSnZGyk6qtliZUySH4z9%2BbLAEeTs%3D&reserved=0>
>> @_nat_en
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://developer.pingidentity.com/en/signup.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1

2020-04-09 Thread Rob Otto
I'd imagine you have to pre-register each client and then use HOTP or TOTP
to generate one-time passcodes.



On Thu, 9 Apr 2020 at 08:25, Daniel Fett  wrote:

> Hi Francis,
>
> Am 08.04.20 um 23:59 schrieb Francis Pouatcha:
>
> As a replacement of RFC 6749 I am missing a "Direct Grant" with the same
> simplicity as the "Resource Owner Password Credentials" grant of RFC 6749..
>
> The reason is that browser redirects are too complex and most of the time
> badly implemented by small teams. For the sake of having SMEs use oAuth 2..1
> with their limited development capacities, I suggest keeping the simple 
> "Resource
> Owner Password Credentials" with an OTP replacing the permanent password.
>
> How does the Client get the OTP in that case?
>
> -Daniel
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/lp/e/enabling-work-from-home-with-MFA.html>
*If you’re not a current customer, click here
<https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_source=Email&utm_campaign=WF-COVID19-New-EMSIG>
for
a more relevant offer.*

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

2018-05-17 Thread Rob Otto
eceives for a new token that it can use to call a downstream
> >> service. And that service in turn might do another exchange to get a new
> >> token suitable to call yet another downstream service. And again and so
> on
> >> and turtles all the way. I'm not necessarily endorsing that level of
> >> granularity in chaining but it's bound to happen somewhere/sometime. The
> >> nested actor claim is able to express that all that has happened with
> the
> >> top level or outermost one being the system currently using the token
> and
> >> prior systems being nested.. What actually gets done with that
> information
> >> is up to the respective systems involved. There might be policy about
> what
> >> system is allowed to call what other system that is enforced. Or maybe
> the
> >> info is just written to an audit log somewhere. Or something else. I
> don't
> >> know. But whatever it is application/deployment/policy dependent and not
> >> specifiable by a spec.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla  wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem
> >>> generally OK. I do still have one remaining concern, which is about
> >>> the actor claim. Specifically, what is the RP supposed to do when they
> >>> encounter it? This seems kind of underspecified.
> >>>
> >>> In particular:
> >>>
> >>> 1. What facts am I supposed to know here? Merely that everyone in
> >>>the chain signed off on the next person in the chain acting as them?
> >>>
> >>> 2. Am I just supposed to pretend that the person presenting the token
> >>>is the identity at the top of the chain? Say I have the
> >>>delegation A -> B -> C, and there is some resource which
> >>>B can access but A and C cannot, should I give access?
> >>>
> >>> I think the first question definitely needs an answer. The second
> >>> question I guess we could make not answer, but it's pretty hard
> >>> to know how to make a system with this left open..
> >>>
> >>> -Ekr
> >>>
> >>>
> >>> ___
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>
> >>
> >> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> >> material for the sole use of the intended recipient(s). Any review, use,
> >> distribution or disclosure by others is strictly prohibited..  If you
> have
> >> received this communication in error, please notify the sender
> immediately
> >> by e-mail and delete the message and any file attachments from your
> >> computer. Thank you.
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> > material for the sole use of the intended recipient(s). Any review, use,
> > distribution or disclosure by others is strictly prohibited..  If you
> have
> > received this communication in error, please notify the sender
> immediately
> > by e-mail and delete the message and any file attachments from your
> > computer. Thank you.
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> --
> Bill Burke
> Red Hat
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

2018-07-20 Thread Rob Otto
I support this as well

On Fri, 20 Jul 2018 at 15:22, Brian Campbell  wrote:

> +1
>
> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss <
> wdenniss=40google@dmarc.ietf.org> wrote:
>
>> I support adoption of this document by the working group.
>>
>>
>> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef <
>> rifaat.i...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> This is the call for adoption of the 'JWT Response for OAuth Token
>>> Introspection' document following the presentation by Torsten at the
>>> Montreal IETF meeting where we didn't have a chance to do a call for
>>> adoption in the meeting itself.
>>>
>>> Here is presentation by Torsten:
>>>
>>> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00
>>>
>>> Here is the document:
>>>
>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01
>>>
>>> Please let us know by August 2nd whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth working
>>> group.
>>>
>>> Regards,
>>> Hannes & Rifaat
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo]
<https://plus.google.com/u/0/114266977739397708540> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.gartner.com/doc/reprints?id=1-5423XKW&ct=180620&st=sb>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth