Re: [OAUTH-WG] [Editorial Errata Reported] RFC7519 (5648)

Its a good suggestion. Curious if you’ll get any reaction. > On Mar 8, 2019, at 3:33 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC7519, > "JSON Web Token (JWT)". > > -- > You may review the report below and at

Re: [OAUTH-WG] expires_in

We don’t issue expires_in for two reasons 1) we have variable length access tokens who’s lifetime can be extended through activity and we find clients misinterpret expires_in to be absolute (or have no practical means of finding out when it updates) 2) we find it actually makes things worse - wit

Re: [OAUTH-WG] Device Flow Implementations

Salesforce has an implementation: https://releasenotes.docs.salesforce.com/en-us/spring17/release-notes/rn_security_auth_device_flow.htm - cmort On Jan 4, 2018, at 5:27 AM, Rifaat Shekh-Yusef wrote: All, As part of the write-up for the Device Flow document, we are looking for information about

Re: [OAUTH-WG] Token Exchange - IPR Disclosure

I am not aware of any IPR on the token exchange document. On Thu, Nov 23, 2017 at 8:14 AM, Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the Token Exchange document, we need an IPR > disclosure from all of you. > > Are you aware of any IPR related to the following Token Ex

Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)?

+1 for cid > On Jun 21, 2016, at 7:35 AM, John Bradley wrote: > > I prefer “cid” as the claim name rather than trying to match the parameter > name. > > John B. >> On Jun 20, 2016, at 6:22 PM, Justin Richer wrote: >> >> +1 for “cid”, consistent with other JWT claims. >> >> — Justin >> >>> On Ju

Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)

ed when > plain was the only option. > > John B. > > On Jan 22, 2016, at 8:45 PM, Chuck Mortimore > wrote: > > We quietly rolled out PKCE support at Salesforce a year ago, as well. > We're on a slightly earlier draft, but look to be compliant with final RFC > with

Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)

We quietly rolled out PKCE support at Salesforce a year ago, as well. We're on a slightly earlier draft, but look to be compliant with final RFC with one exception - we default to S256, and do not have support for "plain" Would be interesting to interop test our deployments. -cmort On Mon, Jan 1

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

The spec is very clear for most cases, but I think it could use some guidance on nested JWTs.(Or perhaps I've got the approach wrong.) Here's the use-case: We have devices that are self-issuing keys.Via token exchange, we're going to except a self-signed JWT from the device that includes a

Re: [OAUTH-WG] Use of Token Exchange spec for API Federation

o at least bind it to client though. > > > Knowing your use case is really valuable. Thanks for describing it for us. > > > > -- Mike > > > > *From:* Chuck Mortimore [mailto:cmortim...@salesforce.com]

Re: [OAUTH-WG] Use of Token Exchange spec for API Federation

Adam Lewis < adam.le...@motorolasolutions.com> wrote: > Hi Chuck, > > Wouldn't the ACDC be a closer fit to what you are doing? Not saying token > exchange couldn't work, but ACDC is specifically targeting your use case. > > -adma > > On Wed, Ju

Re: [OAUTH-WG] Use of Token Exchange spec for API Federation

, Anthony Nadalin wrote: > So in your scenario where you have client (c), user (u), resource (r) > and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 > ? > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Chuck > Morti

[OAUTH-WG] Use of Token Exchange spec for API Federation

We're examining the use of the Token Exchange spec for API federation use-cases, and are looking for some feedback. The basic use-case is as follows: Developer wants to build an Application that is a composite of backend services that span multiple security domains. For example, it's a combinat

Re: [OAUTH-WG] SPOP - code verifier requirements

er is created by base64url encoding the binary value so that you do not need to encode it when sending it over? =nat via iPhone Oct 16, 2014 00:27、Chuck Mortimore のメッセージ: We went with base64url in our implementation On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura wrote: > In his mail, Mike asked

Re: [OAUTH-WG] SPOP - code verifier requirements

We went with base64url in our implementation On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura wrote: > In his mail, Mike asked whether code verifier is > a value that is sendable without trnasformation > as a http parameter value, or if it needs to be > % encoded when it is being sent. > > We have

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement." I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html -cmort On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra wrote:

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

mort On Wed, May 14, 2014 at 2:40 PM, Anthony Nadalin wrote: > There are folks that are not implementing connect for various reasons > (i.e. security reasons, complexity reasons, etc.). thus this is compatible > with connect if folks want to move on to connect, we surely don’t us

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

at 10:23 AM, George Fletcher wrote: > > I also would like to see the WG not focus on another authentication > mechanism and instead look at work like Brian suggested. > > Thanks, > George > > On 5/14/14, 11:41 AM, Chuck Mortimore wrote: > > Agree with Brian and Justin h

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

> > > The IETF needs a draft that enables and provides user authentication > information to clients. > Why? -cmort > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > On May 14, 2014, at 9:39 AM, Chuck Mortimor

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Can you point to one publicly available or publicly documented implementation of a4c?I've never seen one. I will say the a4c spec is almost 100% overlapped with OpenID Connect. Some minor variations in claim names, but it adds 0 incremental value over what we have in Connect. Connect is being

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Agree with Brian and Justin here. Work is already covered in Connect - cmort On May 14, 2014, at 8:39 AM, Justin Richer wrote: I agree with Brian and object to the Authentication work item. I think there’s limited interest and utility in such a draft, especially now that OpenID Connect has be

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Salesforce supports this > On Apr 25, 2014, at 6:11 AM, John Bradley wrote: > > The JWT bearer spec is used in Connect for authenticating clients with > asymmetric credentials. > > I don't know at the moment how many server implementations support that as it > is not MTI. > > I know it is on th

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

I do not have, nor am I aware of any, IPR on any of the technology in the document. thanks -cmort On Wed, Apr 23, 2014 at 1:40 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > I am working on the shepherd writeup for the JWT bearer document. The > shepherd write-ups for

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Salesforce Implementation: https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm&language=en_US On Thu, Apr 24, 2014 at 3:41 PM, Mike Jones wrote: > I am aware of these implementations: > Microsoft Azure Active Directory: > http://azure.microsoft.com/en-us/services

Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

n this is posted as a JWT bearer assertion, the token endpoint a) verifies that the outer signature matches the public key, b) that the public key matches the thumbprint signed into the inner id token, and c) that the signature on the id token is valid. It can than act as then issue a token resp

Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

client an assertion that can be used by the related backend to get > it's own AT, allowing the clients to have different client_id and proof > keys. (builds on Connect id_token used in jwt assertion flow) > > John B. > > On Apr 13, 2014, at 1:17 AM, Mike Jones > wrote: >

Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

ple confirmation keys, it can always defined > a "jwks" element and the handling rules for it, and go for it... > > > > -- Mike > > > > *From:* Chuck Mortimore [mailto:cmortim...@salesforce.com] >

Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

Good start here Mike! One quick question - I see the "cnf" member is defined as a JWK. Why not a JWK Set?I could see use-cases for binding in multiple keys. -cmort On Tue, Apr 1, 2014 at 8:36 PM, Mike Jones wrote: > I've written a concise Internet-Draft on proof-of-possession for JWTs

Re: [OAUTH-WG] Proof-of-Possession (PoP) Architecture Document

Nice document. One quick question In Section 6, on the use of asymmetric keys, it is stated "If the client generates the key pair it includes a fingerprint of the public key (of the SubjectPublicKeyInfo structure, more precisely). The authorization server would include this fingerprint in the a

Re: [OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06)

On Mon, Nov 4, 2013 at 10:45 AM, Brian Campbell wrote: > On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig > wrote: > > You write: > > > > " > > 3. The JWT MUST contain an "aud" (audience) claim containing a > > value that identifies the authorization server as an intended > >

Re: [OAUTH-WG] audience (was draft-ietf-oauth-saml2-bearer-17)

On Mon, Nov 4, 2013 at 11:58 AM, Brian Campbell wrote: > On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig > wrote > > Item #2: You wrote: > > > > " > > Section 2.5.1.4 of Assertions and Protocols for the OASIS > > Security Assertion Markup Language [OASIS.saml-core-2.0-os] > > de

Re: [OAUTH-WG] Google doc with salesforce

This would be more appropriate to ask at http://developer.force.com/ That said, you may want to watch this: http://blogs.developerforce.com/developer-relations/2013/09/login-to-your-salesforce-org-with-openid-connect-in-winter-14.html On Mon, Oct 7, 2013 at 7:28 AM, Sunil Pal wrote: > Hi all,

Re: [OAUTH-WG] Oauth Server to Server

Open to how it can be improved. What information do you think would be helpful? ( we may be too close to the situation to know what's missing ) On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso wrote: > Hi Chuck, > > On Sep 24, 2013, at 6:56 PM, Chuck Mortimore > wrote

Re: [OAUTH-WG] Oauth Server to Server

p 24, 2013 at 8:17 AM, Antonio Sanso wrote: > Hi chuck, > > > On Sep 24, 2013, at 4:57 PM, Chuck Mortimore > wrote: > > I'm not sure I understand your point here. I don't believe there is > anything custom or special about the google implementation here vs JWT

Re: [OAUTH-WG] Oauth Server to Server

I'm not sure I understand your point here. I don't believe there is anything custom or special about the google implementation here vs JWT. It looks identical to our implementation. Can you elaborate? - cmort On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: Hi Brian, thanks a lot for your

Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth

Hey Prateek - and suggested improvements for the SAML Bearer draft? On Mar 21, 2013, at 1:28 PM, prateek mishra wrote: > Mike, Nat - > > I am honestly not sure what to propose in terms of wording > clarification. has a specific meaning in SAML and thats different > from its current meaning in

Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

Same comment as Brian.I support Mike's proposed text. -cmort On Jan 18, 2013, at 3:32 PM, Brian Campbell wrote: I apologize for not participating in much of the discussion around this - I've been otherwise occupied this week with a myriad of other priorities at work. I would, however, like

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

ot be limited by bear assertion, right? Chuck Mortimore mailto:cmortim...@salesforce.com>> 写于 2012-12-14 10:34:13: > You want a holder of key pattern. The draft touches on it > > >The protocol parameters and processing rules defined in this document >are inten

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

s to prove he knows some credential corresponding to his ID, who is delegated some rights. If assertion framework want to support this use case, then generation of assertion should be relaxed, otherwise new work is required to support the use case. Chuck Mortimore mailto:cmortim...@salesforce.c

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

". So how does the STS trust the client? Presumably if it is trusted it has some level of authentication, yes? -cmort Chuck Mortimore mailto:cmortim...@salesforce.com>> 写于 2012-12-14 00:39:03: > The language is simply meant to help illustrate how the framework > mig

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

The language is simply meant to help illustrate how the framework might be used. How do you think it will restrict usage? How could it be improved? -cmort On Dec 12, 2012, at 11:04 PM, mailto:zhou.suj...@zte.com.cn>> wrote: In "section 3 The token service is the assertion issuer; its ro

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

;> wrote: Obviously, it is not so clear from the language there. Chuck Mortimore mailto:cmortim...@salesforce.com>> 写于 2012-12-04 10:17:12: > There's no reason why it can't be resource owner today. > > On Dec 3, 2012, at 6:06 PM, > mailto:zhou.suj...@zte.co

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

There's no reason why it can't be resource owner today. On Dec 3, 2012, at 6:06 PM, mailto:zhou.suj...@zte.com.cn>> mailto:zhou.suj...@zte.com.cn>> wrote: +1. And why it was not looked at that time? oauth-boun...@ietf.org 写于 2012-12-04 01:30:55: > Actually, I

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

3, 2012, at 6:12 PM, Chuck Mortimore wrote: It's simply the entity that created the assertion. Third party token service was meant to encapsulate pretty much all of your stakeholders below. The only one it doesn't really cover is Authorization Server. On Dec 3, 2012, at 12:

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

It's simply the entity that created the assertion. Third party token service was meant to encapsulate pretty much all of your stakeholders below. The only one it doesn't really cover is Authorization Server. On Dec 3, 2012, at 12:35 AM, Nat Sakimura wrote: Hi Brian, The assertion frame

Re: [OAUTH-WG] draft-ietf-oauth-assertions-06

is.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4. Brian Campbell and Chuck Mortimore may be able to provide similar data for use of the SAML Profile. -- Mike From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oa

Re: [OAUTH-WG] Authorization Request via back channel / direct communication?

Hey Adam... There's been a bunch of work done adapting OAuth to enterprise use-cases. Check out the oauth assertions draft and the saml and jwt bindings. In addition, a number of deployments have established strong patterns for using the more common flows in enterprise settings. I'd be h

Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03

Just catching up here - thanks for the comments Hannes. Did you merge these in by yourself? -cmort On May 24, 2012, at 11:39 AM, Hannes Tschofenig wrote: > Hi Chuck, Mike, Brian, and Yaron, > > I reviewed the document as part of my shepherding role and I believe there is > still room for im

Re: [OAUTH-WG] WGLC on Assertion Drafts

Hi Zachary - sorry about the delay in responding. Perhaps the language is a bit confusing - let me explain the intent and see if it makes sense and if you have a recommendation on how it could be made clearer. All this is really saying is that the Authorization server must validate the signatur

Re: [OAUTH-WG] Assertions (was Agenda Proposal)

I'll be there to help support this part of the discussion as well. -cmort On 3/14/12 3:49 PM, "Brian Campbell" wrote: Unfortunately I will not be in Paris for the Thrus meeting but I'd love to see the assertion drafts progress. So thanks to Hannes for putting it on the agenda and to Mike for o

Re: [OAUTH-WG] Are there any implementations of the SAML bearer token specificiation?

Salesforce has an implementation of both the SAML and JWT Bearer tokens. Happy to chat. -cmort On Mon, Mar 12, 2012 at 8:55 AM, Alex Bilbie wrote: > Hello, > > Can anyone please tell me if there are any implementations of the OAuth 2 > SAML bearer tokens draft specification? > > It is our inten

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

If it's not already implicit by our implementation, I'm voicing our support for this becoming a working group item. - cmort On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" mailto:tors...@lodderstedt.net>> wrote: Hi all, I just published a new revision of the token revocation draft. We add

Re: [OAUTH-WG] New Assertion Draft for review

Thanks. /thomas/ __ > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Chuck Mortimore > Sent: Saturday, June 18, 2011 3:42 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] New Assertion Draft for review > > A number of us in th

[OAUTH-WG] New Assertion Draft for review

A number of us in the community have been working on a general model for the use of Assertions in OAuth2 for both client authentication, as well as authorization grants. We've reached general consensus on a doc that I've published as a draft: http://www.ietf.org/id/draft-mortimore-oauth-assert

Re: [OAUTH-WG] Updated text for Native Apps

Agree with Torsten's assessment here. From: Eran Hammer-Lahav [e...@hueniverse.com] Sent: Thursday, June 16, 2011 8:34 AM To: Lodderstedt, Torsten; Chuck Mortimore; oauth@ietf.org Subject: RE: Updated text for Native Apps Tony said a new text is c

Re: [OAUTH-WG] Text for Native Applications

We don't at all this recommend this type of deployment model for Heroku ( or any platform for that manner ). We support injecting environment variables at runtime to avoid this problem. Example: $ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190 Adding config vars: S3_KEY

Re: [OAUTH-WG] Text for Native Applications

On 6/1/11 12:20 AM, "Brian Eaton" wrote: On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt wrote: > I'm getting confused. This thread is about native apps. So why discuss > security considerations for web apps here? They overlap because they both use refresh tokens. =/ When people propos

Re: [OAUTH-WG] Text for Native Applications

client. For JS Apps we support the implicit grant with no refresh token -cmort On 6/1/11 12:16 AM, "Brian Eaton" wrote: On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore wrote: > This is one reason we've favored implicit for native apps. OK, so are you using the implicit g

Re: [OAUTH-WG] Text for Native Applications

On 5/31/11 11:56 PM, "Brian Eaton" wrote: On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore wrote: > It's not entirely necessary; I'm just having a tough time figuring out any > practical difference between the implicit grant flow, and the webserver flow > with n

Re: [OAUTH-WG] Text for Native Applications

e need for credentials on the web server flow. In terms of your example, wouldn't basic XSRF protection in the state param protect? -cmort On 5/31/11 5:37 PM, "Brian Eaton" wrote: On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore wrote: > Updated in language I just sent ou

Re: [OAUTH-WG] Text for Native Applications

The distinction is that the client_secret tends to be a global secret, and there is little ability to protect this type of secret in many common means of application distribution. For example, a iOS app that is shipped through iTunes certainly has access to reasonably secure storage via KeyChai

Re: [OAUTH-WG] Text for Native Applications

his in the comparision with the implicit grant type. regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -Original Message----- From: Chuck Mortimore Sender: oauth-boun...@ietf.org Date: Tue, 24 May 2011 17:30:05 To: oauth@ietf.org Subject: [OAUTH-WG] Text for Native Ap

[OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list -cmort 9. Native Applications A native application is a client which is installed and executes on the end-user's device (i.e. desktop application, native mobile application). Native applications require special

[OAUTH-WG] Text for Native Applications

One of my items from yesterday was to update the text related to native applications. Primary goals were to: 1. remove the explicit preference for authorization_code grant type 2. provide a brief overview on means of initiating authorization requests and receiving callbacks 3. discuss t

Re: [OAUTH-WG] Authorization code security issue (reframed)

We have native clients using the first 3 as well with good success -cmort On 4/4/11 2:00 PM, "Brian Eaton" wrote: On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote: > Very quickly here is the attack... > 1) Paul starts dance at good Client & good AS, App requests authorization. > Note: outbou

Re: [OAUTH-WG] Flowchart for legs of OAuth

In respect to current deployments we have a pretty broad deployment of different clients using implicit grant. We also support the code flow as described here, but haven't found good reason to use it. - cmort On Apr 5, 2011, at 6:24 AM, "Justin Richer" wrote: > Phil, > > It's completely w

Re: [OAUTH-WG] Authorization code security issue (reframed)

Thanks Eran. Well put. As one of the original advocates of MUST, I'll offer a bit of background on what we've done/seen in our 1.0a and 2d10 deployments * we only block HTTP (and javascript:). Other schemes not using TLS are allowed * we've seen 1.0 signatures being much harder for developers

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

+1 I disagree that to use TLS is a big change. Rather I'd categorize using TLS as a big inconvenience. We should define a secure profile. If individual deployments choose to relax the spec and determine HTTP acceptable for local host or other convenience thats fine, but it shouldn't be compl

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

On Mar 24, 2011, at 6:36 PM, "Eran Hammer-Lahav" wrote: > >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Chuck Mortimore >> Sent: Monday, March 14, 2011 6:10 PM > >> 1) I'd vote f

Re: [OAUTH-WG] OAuth JWT Bearer Token Profile

th 2.0 <http://www.ietf.org/id/draft-ietf-oauth-saml2-bearer-03.txt> by Brian Campbell and Chuck Mortimore; it borrows some text from the SAML profile with their permission. Thanks Brian and Chuck, for supporting the writing of this profile and for your reviews of preliminary drafts. Th

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-02

Hey Torsten - glad to see this spec out there, and we plan to implement in the future. Only 1 quick comment: "the authorization server is supposed to detect the token type automatically." I think it would be better to have the client explicitly state the token type. The client will know,

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Draft looks good - readability is up considerably from previous drafts. Getting pretty close IMO Comments: 1) I'd vote for dropping the following from 1.4.2. In turn I'd discuss some of the security considerations, such as difficulty of protecting a client_secret in almost all use-cases o

[OAUTH-WG] Salesforce.com rolling out Draft 10

Just thought I'd let the list know that we rolled out Draft 10 to our first round of customer sandboxes this weekend. We'll continue to roll out to remaining sandboxes, and then our production servers over the next few weeks. All tenants should be live globally by Oct 9th. Along with a fair

Re: [OAUTH-WG] Moving the User Experience Extension draft forward

We are in support, and have implemented display - cmort On Aug 25, 2010, at 1:40 PM, "Marius Scurtescu" wrote: > David, > > Here is some feedback I received internally from Greg Robbins: > > "Having "display" as an extension is useful, though considering the > trend towards tablet devices lik

Re: [OAUTH-WG] more than one assertion?

Personally, I'd first like to see more concrete use-cases of how multiple assertions are going to be used in practice. Tony alluded to some abstract use-cases, but fuller descriptions would probably help everyone out. -cmort On 8/10/10 9:15 AM, "Eran Hammer-Lahav" wrote: WFM. > -Origi

Re: [OAUTH-WG] SAML profile comments/questions from the SAML people

On 8/9/10 9:30 AM, "Brian Campbell" wrote: I received some feedback on the SAML profile from a cross posting on the OASIS SSTC (SAML) list. Links to the thread topic index are below[1], if you are interested, but I'll try and summarize the two primary issues here. First, concern was expresse

Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

Hi Prateek The use-case we were going for here is really more like a classic 2-legged oauth scenario.A company has an existing SAML web federation established with a service provider which is providing SSO to it's users.They now want to perform API based integration with the service pro

Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft

t;> >>>> Why do you want to force a one-time usage for SAML assertions? >>>> This is to restrictive, in my opinion. >>>> >>> >>> This is also a carryover from web SSO via the POST binding. I was >>> actually leaning towards not

Re: [OAUTH-WG] assertion profile changes

s, but I don't think overloading client_id for that is wise. Cheers, Brian On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore wrote: That sounds like a very accurate description to me. -cmort On 7/8/10 3:27 PM, "Brian Campbell" wrote: Maybe I'm the only one havin

Re: [OAUTH-WG] assertion profile changes

use-case ( customers posting SAML assertions with subjects that are only unique when namespaced to a particular IDP ), the client is really defined as a SAML IDP, and I'd be looking up it's metadata based upon the client_id. This seems appropriate to me. -cmort Cheers, Brian On

Re: [OAUTH-WG] assertion profile changes

That sounds like a very accurate description to me. -cmort On 7/8/10 3:27 PM, "Brian Campbell" wrote: Maybe I'm the only one having a hard time following this thread but I suspect I'm not alone. I'm going to try and just summarize the issues - mostly for my own edification but hopefully this

Re: [OAUTH-WG] assertion profile changes

On 7/8/10 12:32 PM, "Yaron Goland" wrote: Here is what I think happened. In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format arguments were used to allow clients to authenticate themselves to token endpoints in two legged OAuth scenarios. In OAuth 2.0 two legged OAuth

Re: [OAUTH-WG] POLL: Are you going to Maastricht?

D On Thursday, July 8, 2010, David Recordon wrote: > B > > On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrote: > > I'm honestly trying to decide myself and a few other people are in similar > situations. Thus a poll:A) Yes, I'm going to be in MaastrichtB) Maybe, > depends on the number of OA

Re: [OAUTH-WG] assertion profile changes

on if they want a new access token I'm a believer that devs will have to reference other docs and specs for the assertion flow. Perhaps making this language stronger would help? -cmort On Wednesday, July 7, 2010, Brian Eaton wrote: > On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore >

Re: [OAUTH-WG] assertion profile changes

This thread forced a great deal on internal discussion today, and we actually do have some more immediate use-cases where we'll require client_id with the assertion flow I support leaving it as optional -cmort On Wednesday, July 7, 2010, Brian Eaton wrote: > On Wed, Jul 7, 2010 at 2:52 PM, Eran

Re: [OAUTH-WG] assertion profile changes

On 7/7/10 3:01 PM, "Brian Eaton" wrote: On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wrote: > I disagree with this approach. There are plenty of optional parameters in > the spec. Yes. I think most of them are a bad idea. > The assertion access grant requires further profiling to be usef

Re: [OAUTH-WG] assertion profile changes

Good catch Brian - client_id and client_secret now seem mandatory when reading draft 9. When those were originally added to the flow, they were clearly marked as optional. That is lost in the latest drafts. We'd be happy with either optional or removed. Mandatory doesn't work for us at al

[OAUTH-WG] Error Code for username/password flow

There doesn't seem to be a proper error code to use with the Username/Password flow. If the client credentials are wrong "incorrect_client_credentials" is used. Nothing is specified if the end-user credentials are incorrect. Suggestion: "invalid_user_credentials" -cmort

Re: [OAUTH-WG] Draft -07 (major rewrite)

+1 for the type parameter. Our internal server and client developers would both prefer it. -cmort From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Justin Richer [jric...@mitre.org] Sent: Monday, June 14, 2010 7:20 AM To: Eran Hamme

Re: [OAUTH-WG] Proposal for single JSON response format

+1 with optional extension for XML encoded -cmort On 6/10/10 1:29 PM, "Eran Hammer-Lahav" wrote: After taking a break from our previous debate(s) on the issue of which response format to support, I would like to suggest the following: - Support a single response format (including in the user

Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow

Did anyone ever write up the specifics of this? I've seen general support, and would like to see it added. -cmort On 5/24/10 2:22 PM, "Eran Hammer-Lahav" wrote: Anyone wants to turn this into an actual proposal with list of changes to the current flow? EHL On 5/23/10 7:13 PM, "Luke Shep

Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

On 6/7/10 6:23 PM, "Marius Scurtescu" wrote: On Mon, Jun 7, 2010 at 5:31 PM, Chuck Mortimore wrote: > Note sure I follow this Marius: > > "What can happen is that exmple.com/back can pretend to be > example.com/back, but registration does not help in this case."

Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri

Note sure I follow this Marius: "What can happen is that exmple.com/back can pretend to be example.com/back, but registration does not help in this case." I believe it does help in this case, as the Authorization server can validate the registered redirect_uri vs. the requested redirect_uri. H

Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow

+1 At the moment we don't intend to issue refresh tokens on the user-agent flow. This would likely change our mind. -cmort On 5/21/10 3:30 PM, "Brian Eaton" wrote: On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrote: > This is a common pattern that other connect-like services built on t

Re: [OAUTH-WG] User and Client identity in the Assertion Flow

Our plan is to treat SAML assertions passed over the assertion flow as bearer assertions, so I believe we have everything we need contained within the assertion (issuer + audience + signature). That being said, if we want this to be an extensible flow, not all assertion formats will be so trans

Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)

iency. Certainly, it adds complexity to regression testing. I appreciate the desire for symmetry on the set of flows...refresh token seems like a place for asymmetry. BillK -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore Sent: Tue

Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)

same purpose. Can we add a >> variant of the >> flow to section "End User Credentials Flows"? >> >> regards, >> Torsten. >> >> Am 26.04.2010 23:17, schrieb Chuck Mortimore: >> >> +1. >> >> Our primary use-cases for the asser

Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)

+1. Our primary use-cases for the assertion flow are for clients acting on behalf of users, and not autonomously. I believe Eran already has this on his list of feedback when the assertion flow gets edited. We also have need for a 2 legged Oauth model, and are looking at the client credentia

Re: [OAUTH-WG] Issue: specificity of the assertion flow

On 4/16/10 5:03 PM, "Brian Eaton" wrote: On Thu, Apr 15, 2010 at 12:38 PM, Chuck Mortimore wrote: > Could you please take another glance at what I posted? There are a number > of changes to the general assertion flow that are required for it to reflect > how this will

Re: [OAUTH-WG] Issue: specificity of the assertion flow

, it doesn't define the format parameter, just gives one fixed value for the SAML flow. Either way, I am suggesting we keep the SAML flow out of the spec, keeping just the general assertion flow, with better format definition. EHL On 4/15/10 11:55 AM, "Chuck Mortimore" wrote:

Re: [OAUTH-WG] Issue: specificity of the assertion flow

+1. Did anyone have a chance to review the proposal I made here?I have a couple of people from the SAML community reviewing it offline, but would welcome feedback from this group. The sample text is attached to this post: http://www.ietf.org/mail-archive/web/oauth/current/msg01735.html O

  1   2   >