Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response?
> I’d be happy to pick it back up if the working group wanted to make it an official document. +1 Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG Date: 06/12/2014 05:18 PM Subject:Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response? I haven’t touched the draft for a while because the basics have fit most of our use cases and there hasn’t been a clamor from the working group to standardize it. I’d be happy to pick it back up if the working group wanted to make it an official document. Having run this in production for a little while, there are a handful of things that would make sense to include in the standard response set. Things like returning the grant type, response type, as it’s all a part of the request that made the token. We’ve also had questions recently about returning both the ‘sub’ of a user as defined by OpenID Connect in addition to a more traditional user_id/username field (our deployment does both, and they’re different — the former is stable but the latter is used to cross-index into other systems). — Justin On Jun 12, 2014, at 4:50 PM, Todd W Lainhart wrote: One problem we've discovered when returning the client_id value as "sub" is client impersonation. That is, in a system where a user can self-register, it's possible that the user could register an id/sub value that is the same as the client_id value, and thus be granted the same privileges as the application principal based on the introspection response. We're leaning towards returning the grant_type in the introspection response to disambiguate this case. i.e. if grant_type == "client_credentials" then you know that the bearer represents the app principal. http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired last Nov. Were you thinking of picking it up? I'm recalling that Nat Sakimura expressed an interest a while back. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From:Justin Richer To:Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG < oauth@ietf.org>, Date:05/22/2014 10:45 AM Subject:Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response? We return the client_id of the client that the token was issued to. -- Justin On 5/22/2014 10:08 AM, Todd W Lainhart wrote: For folks who have implemented the client credentials grant and introspection, I'm interested to know what you're returning for the value of "sub" in the token introspection response ( http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2 ). The "client_id" value requesting the grant, or some other client registration metadata value? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [attachment "signature.asc" deleted by Todd W Lainhart/Lexington/IBM] ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response?
One problem we've discovered when returning the client_id value as "sub" is client impersonation. That is, in a system where a user can self-register, it's possible that the user could register an id/sub value that is the same as the client_id value, and thus be granted the same privileges as the application principal based on the introspection response. We're leaning towards returning the grant_type in the introspection response to disambiguate this case. i.e. if grant_type == "client_credentials" then you know that the bearer represents the app principal. http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired last Nov. Were you thinking of picking it up? I'm recalling that Nat Sakimura expressed an interest a while back. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG , Date: 05/22/2014 10:45 AM Subject:Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response? We return the client_id of the client that the token was issued to. -- Justin On 5/22/2014 10:08 AM, Todd W Lainhart wrote: For folks who have implemented the client credentials grant and introspection, I'm interested to know what you're returning for the value of "sub" in the token introspection response ( http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2 ). The "client_id" value requesting the grant, or some other client registration metadata value? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.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
[OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response?
For folks who have implemented the client credentials grant and introspection, I'm interested to know what you're returning for the value of "sub" in the token introspection response ( http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2 ). The "client_id" value requesting the grant, or some other client registration metadata value? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Another question on RFC 7009
> ...what's the intended way that the "request is refused and the client is informed of the error" when the the token was not issued to the client making the revocation request? We return an error_code of "invalid_request" and an appropriate error message. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Brian Campbell To: oauth , Date: 01/31/2014 11:58 AM Subject:[OAUTH-WG] Another question on RFC 7009 Sent by:"OAuth" Greetings WG, In section 2.1 of RFC 7009, it says: "The authorization server first validates the client credentials (in case of a confidential client) and then verifies whether the token was issued to the client making the revocation request. If this validation fails, the request is refused and the client is informed of the error by the authorization server as described below." The only error described below is "unsupported_token_type" which doesn't seem appropriate here. The errors in http://tools.ietf.org/html/rfc6749#section-5.2 are referenced too and, while "invalid_client" seems right for failed client authentication, what's the intended way that the "request is refused and the client is informed of the error" when the the token was not issued to the client making the revocation request? None of the defined error codes seem to fit. Furthermore, wouldn't it be better to go ahead and just revoke a token in the case it's presented by the wrong client? I seem to recall some discussion around this when 7009 was just a baby draft-ietf-oauth-revocation and, while I don't recall the outcome, I was surprised to look at the RFC again and see the text that is there. These questions came to me by way of a developer working on implementing the RFC. I didn't have good answers, beyond the prognostication herein, so I thought I'd take the questions to the WG list and the document authors. Thanks for any clarification, Brian ___ 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-WG] Introspection spec still active?
http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired as of 11/02/13. I'm assuming that this spec still has some traction, and that the expiration is not an indicator of retraction? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] A couple of questions re dynamic client registration
I'm working off this document for our client registration: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14 Section 4 - Client Configuration Endpoint says this: The client MUST use its registration access token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750]. I'm trying to understand if I should provide a separate administrative endpoint for client configurations (i.e. accessible via an entity with admin credentials/privileges). I think this language is telling me "yes". What are the client options for read/update/delete should this access token be lost? I read "none". Section 4.1 - Section 4.1 says this: The authorization server MUST provide the client with the fully qualified URL in the "registration_client_uri" element of the Client Information Response (Section 5.1). I'm curious as to why this isn't returned in the Location header? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Oauth Server to Server
> From what I read, it sounds like you want either the assertion flow (which is defined in extensions) or the client credentials flow (not the resource owner password flow). I thought the same re "client credentials flow", but on a quick reading of Google's spec, their impl also allows for impersonation, assuming that the client has been registered to allow such (unclear if the original poster also wanted this functionality). We have a similar feature in our impl - client creds flow w/ impersonation (with supporting registration). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Antonio Sanso , Cc: "oauth@ietf.org WG" Date: 09/26/2013 09:41 AM Subject:Re: [OAUTH-WG] Oauth Server to Server Sent by:oauth-boun...@ietf.org From what I read, it sounds like you want either the assertion flow (which is defined in extensions) or the client credentials flow (not the resource owner password flow). In either of these, the client authenticates on its own behalf and gets a token directly with no user involved, and both are fully specified. -- Justin On 09/24/2013 08:08 AM, Antonio Sanso wrote: > Hi *, > > apologis to be back to this argument :). > > Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :) > > At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant. > > Let me tell I am not a big fun of this particular flow :) (but this is another story). > > An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1]. > > Couple of more things: > > - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft?? > > Thanks and regards > > Antonio > > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > ___ > 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
Re: [OAUTH-WG] Unclear parts in OAuth 2.0 specification
Think that there are three different types of clients: confidential; public; and anonymous (my term). Confidential: id and secret; Public: id only; Anonymous: no credentials; You provide the type of credentials that you can, and the protected endpoint will accept or reject based on the operation and its protections. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Martin Ždila To: oauth@ietf.org, Date: 08/30/2013 03:42 AM Subject:[OAUTH-WG] Unclear parts in OAuth 2.0 specification Sent by:oauth-boun...@ietf.org Hello There are some unclear parts in OAuth 2.0 specification. 1. In 4.3. (B) there is following statement: When making the request, the client authenticates with the authorization server. In 4.3.2 there is following statement: If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1. First statement states that client credentials must be always passed. Second states that it is required only for certain client types. Also, if client type doesn't provide credentials, there is no mean to identify it and so impossible to check if client credentials were actually required. 2. Authorization Code Grant and Implicit Grant use different URL part to encode its response. Former uses query and later fragment. If request has invalid or is missing response_type parameter then user agent should be redirected to URL with error response where error=unsupported_response_type. But if we don't know what type of grant we are handling, where to put error parameters? To query or fragment part of the URL? Please clarify that. Thanks in advance Best regards -- Ing. Martin Ždila Senior Analyst / Developer M-Way Solutions Slovakia s.r.o. Letná 27, 040 01 Košice Slovakia tel:+421-908-363-848 mailto:m.zd...@mwaysolutions.com http://www.mwaysolutions.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
Re: [OAUTH-WG] What should happen to access tokens when the end user credentials change
Assuming of course that the AS was notified by the IdP (or could inquire from same, say, during introspection) that something about the user's account had changed - there's nothing in the protocol that speaks to that. Would anyone be surprised if the authorizations granted to the previous confirmation of identity were now void? That seems like the simplest way to handle it. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Barry Leiba To: Sergey Beryozkin , Cc: "" Date: 08/06/2013 08:50 AM Subject:Re: [OAUTH-WG] What should happen to access tokens when the end user credentials change Sent by:oauth-boun...@ietf.org > Suppose a given user has approved a client's grant request and that client > is now working with the access token tied to the user's login name (or some > other representation of that user's login credentials). > > What would be the recommended course of action when that user's credentials > (example, the user's login name) change, as far as the existing access > tokens tied to that user are concerned ? An interesting question. I think it's not the OAuth protocol's concern, but a document describing operations and deployment might suggest what to do. Groping here (I'm not a UI expert): I expect that some changes (and/or some reasons for changes) would make no difference to the authorizations the user has approved. If I change my username from "barryleiba" to "bigkahuna" because I want to be cool, I would want my authorizations to persist. If I change my password because I routinely change my password, I would want my authorizations to persist. If I change my password because I think my old password was compromised, I would want to review my authorizations and make sure nothing untoward is there. Alternatively, I might just want to invalidate all of them and re-establish them as needed afterward. So it would probably be good for the system in question to ask me what to do about the authorizations I've given out, and allow me to review them and address them one by one, and/or make a blanket decision for the lot. Maybe: Your password has been changed. Do you want to revoke authorizations you have approved? [YES / NO] Or maybe: Your password has been changed. Do you want to review authorizations you have approved? [YES / NO] -- Barry ___ 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
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
> I always think I pretty much understand OIDC until I see the specs list It's not just me, then. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Paul Madsen To: Brian Campbell , Cc: "oauth@ietf.org WG" Date: 07/30/2013 12:59 PM Subject:Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt Sent by:oauth-boun...@ietf.org I always think I pretty much understand OIDC until I see the specs list On 7/30/13 12:39 PM, Brian Campbell wrote: Yes, that. On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. wrote: Yes, I agree that the giant stack of documents is intimidating and in my opinion it's a bit of a mess with Messages and Standard split up (but I lost that argument years ago). ___ 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
Re: [OAUTH-WG] AS associated to multiple IdPs
> Typically someone would have a shadow account that would deal with lining the identities from multiple IdP into the local account and assert the local identifier to the RS. Yes, that where I was going. > I would personally treat passing the additional external identifiers as extra claims to the RS. If the AS isn't issuing JWTs, how do you suggest passing this information to the RS? I was thinking of reusing or augmenting fields in the response from token provisioning and introspection. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: John Bradley To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: Prateek Mishra , IETF oauth WG Date: 07/19/2013 12:22 PM Subject:Re: [OAUTH-WG] AS associated to multiple IdPs I think most people look this similarly to SSO account mapping. Typically someone would have a shadow account that would deal with lining the identities from multiple IdP into the local account and assert the local identifier to the RS.I would personally treat passing the additional external identifiers as extra claims to the RS. The relationship between the RS and AS also has impacts on what you pass and how. John B. On 2013-07-19, at 10:52 AM, Todd W Lainhart wrote: Thanks to Prateek and John for the replies. I agree that the required mapping should be done by the AS, and that the user portion of the identity may not be unique (as John said in a later reply). I'm still trying to figure out to if the RS should pass a scope that might be a clue to the AS as to what identity to return, and whether or not the AS can leverage the schema of the introspection response to return the multiple mapped identities (I'll start a separate thread on that). We're not using JWT, so it would have to be introspection. But I think the replies are verifying that multiple IdPs per AS is not unusual, and that the management/mapping those ids is proprietary. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From:Prateek Mishra To:Todd W Lainhart/Lexington/IBM@IBMUS, Cc:IETF oauth WG Date:07/18/2013 09:48 PM Subject:Re: [OAUTH-WG] AS associated to multiple IdPs Todd - doesnt the AS have adequate "scope" information to guess which resource server the token might get delivered to? I am afraid thats about as far as the OAuth flows go in capturing the "target" of the final request. Couldn't the "scope" information be used by the AS to decide between including "jdoe" or "j...@gmail.com" in the access token? It seems to me that all of the required mapping could be completed by the AS. - prateek This is not specifically an OAuth question per se, but there's enough experience here from multiple domains (e.g. OIDC, UMA, SCIM) that someone might be able to give me a pointer. I'm considering the case where an authorization server is associated to multiple IdPs, such that identity could come from LDAP or (say) Google. In such a set-up, the identity that the AS associates to a bearer token might be "jdoe" (LDAP) or "j...@gmail.com" (Google). When a resource server performs an introspection on such a token, they're either returned "jdoe" or "j...@gmail.com", depending upon what IdP the resource owner chose to authenticate to. A couple of questions re this setup: 1) First, is the cardinality between AS and IdP reasonable (AS(*) <==> IdP(1-n)), and if so, is there precedent and best practice that I can study? 2) Assuming "true" for "1" above... In the case where the AS is performing the role of SSO provider to multiple resource servers, I'm imagining a setup where it is desireable that all resource servers associated to that AS see the user principal identifier that makes sense to them. E.G. Resource Server "A" prefers the "jdoe" identity; Resource Server "B" prefers the "j...@gmail.com" identity. When "A" or "B" receives a bearer token via back channels, provisioned by the AS to "John Doe", introspection reveals, directly or indirectly, the identity "A" and "B" prefer. That suggests that either there's a user registry where "A" and "B" can ask for the identity aliases associated to the generalized token-identity that they received (e.g. mapped to "john.doe"), or the response from introspection widens (perhaps in a proprietary way) to include these aliases (e.g. authenticated principal: "john.doe"; aliases: "jdoe"; "j...@gmail.com"). In both cases, there's a ma
Re: [OAUTH-WG] Token introspection: "aud" field in introspection response
Thanks. Is it assumed/valid that the "aud" field can be used in non-JWT environs? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG Date: 07/19/2013 11:16 AM Subject:Re: [OAUTH-WG] Token introspection: "aud" field in introspection response The "aud" field came from JWT: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-10#section-4.1.3 The links in section 2.2 are correct -- they link to the reference in section 6, which has the URL for the actual RFC of OAuth 2.0 there. I agree that it's a weird way to handle hyperlinks, but that's what the xml2rfc program outputs and I don't have control over that (that I'm aware of). -- Justin On 07/19/2013 11:05 AM, Todd W Lainhart wrote: http://tools.ietf.org/html/draft-richer-oauth-introspection-04#page-3 lists the "aud" field as an optional field in the introspection response. Could someone give examples of its intended use? Did this come from OIDC? Also Justin - it appears that the section links to the OAuth 2.0 spec in Section 2.2 are broken - they point back to the introspection doc. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.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
Re: [OAUTH-WG] AS associated to multiple IdPs
Thanks to Prateek and John for the replies. I agree that the required mapping should be done by the AS, and that the user portion of the identity may not be unique (as John said in a later reply). I'm still trying to figure out to if the RS should pass a scope that might be a clue to the AS as to what identity to return, and whether or not the AS can leverage the schema of the introspection response to return the multiple mapped identities (I'll start a separate thread on that). We're not using JWT, so it would have to be introspection. But I think the replies are verifying that multiple IdPs per AS is not unusual, and that the management/mapping those ids is proprietary. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Prateek Mishra To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG Date: 07/18/2013 09:48 PM Subject:Re: [OAUTH-WG] AS associated to multiple IdPs Todd - doesnt the AS have adequate "scope" information to guess which resource server the token might get delivered to? I am afraid thats about as far as the OAuth flows go in capturing the "target" of the final request. Couldn't the "scope" information be used by the AS to decide between including "jdoe" or "j...@gmail.com" in the access token? It seems to me that all of the required mapping could be completed by the AS. - prateek This is not specifically an OAuth question per se, but there's enough experience here from multiple domains (e.g. OIDC, UMA, SCIM) that someone might be able to give me a pointer. I'm considering the case where an authorization server is associated to multiple IdPs, such that identity could come from LDAP or (say) Google. In such a set-up, the identity that the AS associates to a bearer token might be "jdoe" (LDAP) or "j...@gmail.com" (Google). When a resource server performs an introspection on such a token, they're either returned "jdoe" or "j...@gmail.com", depending upon what IdP the resource owner chose to authenticate to. A couple of questions re this setup: 1) First, is the cardinality between AS and IdP reasonable (AS(*) <==> IdP(1-n)), and if so, is there precedent and best practice that I can study? 2) Assuming "true" for "1" above... In the case where the AS is performing the role of SSO provider to multiple resource servers, I'm imagining a setup where it is desireable that all resource servers associated to that AS see the user principal identifier that makes sense to them. E.G. Resource Server "A" prefers the "jdoe" identity; Resource Server "B" prefers the "j...@gmail.com" identity. When "A" or "B" receives a bearer token via back channels, provisioned by the AS to "John Doe", introspection reveals, directly or indirectly, the identity "A" and "B" prefer. That suggests that either there's a user registry where "A" and "B" can ask for the identity aliases associated to the generalized token-identity that they received (e.g. mapped to "john.doe"), or the response from introspection widens (perhaps in a proprietary way) to include these aliases (e.g. authenticated principal: "john.doe"; aliases: "jdoe"; "j...@gmail.com"). In both cases, there's a mapping between the aliases outside of the participating resource servers. If this second question made sense, I'm looking for precedents and insights (or better practice). I'm wondering if SCIM plays a role here. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.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
[OAUTH-WG] Token introspection: "aud" field in introspection response
http://tools.ietf.org/html/draft-richer-oauth-introspection-04#page-3 lists the "aud" field as an optional field in the introspection response. Could someone give examples of its intended use? Did this come from OIDC? Also Justin - it appears that the section links to the OAuth 2.0 spec in Section 2.2 are broken - they point back to the introspection doc. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant
I agree that 429 seems to be the more appropriate status code for this case - I wasn't aware of these extensions. Re how to reconcile application errors/status that are outside the OAuth domain, I've also struggled with that a bit. My current position is to try and fit the error response within the OAuth error reporting framework as much as is possible and reasonable. For example, with the account lockout problem, I would return some HTTP-level status code (401, 403, or 429), using the OAuth error schema in the response body. The error_code might be invalid_request, and then the body describing exactly what the problem was. I'm a bit conflicted on this, but in practice, I've found that most programmatic clients will not disambiguate the 401/403/429, and just want to know if this was an authentication problem, and what text to return to the user. The problem then becomes what text to return, as the text in error_description is US_ASCII, and may not be appropriate for the locale of the client. So it may be that a custom error_code is the way out. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: André DeMarre To: Todd W Lainhart/Lexington/IBM@IBMUS, Justin Richer , Cc: Santiago Pérez , OAuth WG Date: 07/18/2013 06:22 PM Subject:Re: [OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant This question exposes a shortcoming of the final spec. After implementing an authorization server, I've formed the opinion that the spec doesn't define clearly enough the auth server's behavior at the token endpoint. Implementers do not know what discretion they are entitled when trying to reconcile OAuth behavior with scenarios that are outside the scope of the OAuth spec. The original question about throttling authentication attempts is a perfect example. Section 5.2 (token endpoint error response) is very specific, but it doesn't give any allowance for handling errors that are not OAuth-specific. So if resource owner credentials cannot be accepted because of previous unsuccessful attempts, does that mean the response at the token endpoint is not an OAuth response at all and the server is free to respond with HTML if it so chooses? It could be that the client has done nothing wrong and is following the spec perfectly, so it seems appropriate that the auth server should send an error response that complies with Section 5.2. None of the defined error codes are appropriate, so I suppose the server could use an unregistered error code as permitted by Secion 8.5. Is that correct? I'm inclined to agree with Justin that 429 is a good HTTP status code here, but the spec is unclear about the use of 4xx status codes beyond 400 and 401. In March I asked a similar (unanswered) question regarding the use of 405: http://www.ietf.org/mail-archive/web/oauth/current/msg11192.html The crux is that authorization server implementers are given no direction when solving problems in that gray area where the problem is outside the scope of OAuth, but they still want their server to respond in a way that is comprehensible by OAuth clients. If you think I'm looking at this wrong, I'd like to hear about it. http://tools.ietf.org/html/rfc6749#section-5.2 http://tools.ietf.org/html/rfc6749#section-8.5 Regards, Andre DeMarre On Wed, Jul 17, 2013 at 8:57 AM, Todd W Lainhart wrote: Why wouldn't you return an HTTP-level status code of 401, with perhaps some text describing the account lock-out? Or a 403 if you wanted a separate lockout status code. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From:Santiago Pérez To:oauth@ietf.org, Date:07/17/2013 11:09 AM Subject:[OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant Sent by:oauth-boun...@ietf.org Dear all, We are implementing a OAuth 2.0 server and there is a point that is not clear for me in the RFC 6749. What error should we return when the maximum number of attempts for resource owner credentials is exceeded? I can not see any suitable error in the current RFC. We are implementing a policy for controlling this X attempts per period (e.g.: 3 times/15 minutes) Thanks for your answer. Kind Regards, Santiago Pérez___ 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
Re: [OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant
Why wouldn't you return an HTTP-level status code of 401, with perhaps some text describing the account lock-out? Or a 403 if you wanted a separate lockout status code. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Santiago Pérez To: oauth@ietf.org, Date: 07/17/2013 11:09 AM Subject:[OAUTH-WG] Throttling error using resource owner password credentials grant or authorization code grant Sent by:oauth-boun...@ietf.org Dear all, We are implementing a OAuth 2.0 server and there is a point that is not clear for me in the RFC 6749. What error should we return when the maximum number of attempts for resource owner credentials is exceeded? I can not see any suitable error in the current RFC. We are implementing a policy for controlling this X attempts per period (e.g.: 3 times/15 minutes) Thanks for your answer. Kind Regards, Santiago Pérez___ 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-WG] AS associated to multiple IdPs
This is not specifically an OAuth question per se, but there's enough experience here from multiple domains (e.g. OIDC, UMA, SCIM) that someone might be able to give me a pointer. I'm considering the case where an authorization server is associated to multiple IdPs, such that identity could come from LDAP or (say) Google. In such a set-up, the identity that the AS associates to a bearer token might be "jdoe" (LDAP) or "j...@gmail.com" (Google). When a resource server performs an introspection on such a token, they're either returned "jdoe" or "j...@gmail.com", depending upon what IdP the resource owner chose to authenticate to. A couple of questions re this setup: 1) First, is the cardinality between AS and IdP reasonable (AS(*) <==> IdP(1-n)), and if so, is there precedent and best practice that I can study? 2) Assuming "true" for "1" above... In the case where the AS is performing the role of SSO provider to multiple resource servers, I'm imagining a setup where it is desireable that all resource servers associated to that AS see the user principal identifier that makes sense to them. E.G. Resource Server "A" prefers the "jdoe" identity; Resource Server "B" prefers the "j...@gmail.com" identity. When "A" or "B" receives a bearer token via back channels, provisioned by the AS to "John Doe", introspection reveals, directly or indirectly, the identity "A" and "B" prefer. That suggests that either there's a user registry where "A" and "B" can ask for the identity aliases associated to the generalized token-identity that they received (e.g. mapped to "john.doe"), or the response from introspection widens (perhaps in a proprietary way) to include these aliases (e.g. authenticated principal: "john.doe"; aliases: "jdoe"; "j...@gmail.com"). In both cases, there's a mapping between the aliases outside of the participating resource servers. If this second question made sense, I'm looking for precedents and insights (or better practice). I'm wondering if SCIM plays a role here. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Device profile usage
> The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app? I asked, because I wondered if the client credentials flow or the auth code flow was the more appropriate flow. It sounds like you want to identify both the client and the user, but it's unclear if it's required that the client authenticate. Also, I can't tell from your use case if OAuth is the appropriate solution. If it is the right solution, Justin's response sounds like the way to go. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Vincent Tsang To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: "oauth@ietf.org" , "oauth-boun...@ietf.org" , Nat Sakimura Date: 05/29/2013 10:29 AM Subject:Re: Device profile usage The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app? Thanks. Vincent On Wednesday, May 29, 2013, Todd W Lainhart wrote: On behalf of what will the access token be granted - the app (e.g. Word), or the user running the app? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From:Vincent Tsang To:Nat Sakimura , Cc:"oauth@ietf.org" Date:05/29/2013 12:31 AM Subject:Re: [OAUTH-WG] Device profile usage Sent by:oauth-boun...@ietf.org The client is a native windows application, for instance, a document editor like MS Word. The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens). I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API. I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here... Thanks. Vincent On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura wrote: A little more application and user context would help. A use case, so to speak. Nat 2013/05/29 12:04、Vincent Tsang のメッセージ: > Hi Hannes, > > Thanks for your reply. > Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed. > Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application. > I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully. > Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications? > > Thanks. > Vincent > > ___ > 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
Re: [OAUTH-WG] Device profile usage
On behalf of what will the access token be granted - the app (e.g. Word), or the user running the app? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Vincent Tsang To: Nat Sakimura , Cc: "oauth@ietf.org" Date: 05/29/2013 12:31 AM Subject:Re: [OAUTH-WG] Device profile usage Sent by:oauth-boun...@ietf.org The client is a native windows application, for instance, a document editor like MS Word. The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens). I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API. I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here... Thanks. Vincent On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura wrote: A little more application and user context would help. A use case, so to speak. Nat 2013/05/29 12:04、Vincent Tsang のメッセージ: > Hi Hannes, > > Thanks for your reply. > Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed. > Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application. > I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully. > Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications? > > Thanks. > Vincent > > ___ > 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
Re: [OAUTH-WG] OAuth Feature Matrix
Are you interested in survey results from non-meeting members? If so, where/how do you want that posted? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Mike Jones To: "oauth@ietf.org" , Date: 03/11/2013 06:39 PM Subject:[OAUTH-WG] OAuth Feature Matrix Sent by:oauth-boun...@ietf.org The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG meeting today is attached and available at http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx. Tony Nadalin and I created it as a tool to characterize OAuth implementations to help promote interoperability by understanding the choices that different implementers have made. Also as discussed today, I propose that people with implementations get together tomorrow (Tuesday) afternoon to take a quick pass at characterizing the choices made in your implementations to date. Then we can report back to the working group on Thursday with a snapshot of the choices made, which will help us get a sense of which features are likely to be interoperable across implementations. (Actually, all those who are interested are welcome, not just those with implementations.) I’ll create a Doodle poll now to help us choose a time window between 1:00 and 5:00 to get together and do this. Also, stay tuned for the room where we’ll meet. Hopefully this will be a useful and informative exercise… -- Mike [attachment "OAuth Feature Matrix.xlsx" deleted by Todd W Lainhart/Lexington/IBM] ___ 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
Re: [OAUTH-WG] draft-richer-oauth-introspection-03
> ...but I see no reason that these two items couldn't be incorporated with the same language and semantics. That's great. "token_type_hint" is something that could be helpful to implementations. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG Date: 03/07/2013 11:28 AM Subject:Re: [OAUTH-WG] draft-richer-oauth-introspection-03 I hadn't set out to make the introspection draft parallel to the revocation draft, but I see no reason that these two items couldn't be incorporated with the same language and semantics. -- Justin On 03/07/2013 10:23 AM, Todd W Lainhart wrote: I forgot to include the "token_type_hint" parameter in the baseline compare (i.e. revocation includes it as optional, introspection does not). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From:Todd W Lainhart/Lexington/IBM@IBMUS To:"IETF oauth WG" , Date:03/07/2013 10:17 AM Subject:[OAUTH-WG] draft-richer-oauth-introspection-03 Sent by:oauth-boun...@ietf.org Hi Justin - I'm comparing: http://tools.ietf.org/html/draft-richer-oauth-introspection-03 ...with: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 for symmetry. If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-richer-oauth-introspection-03
I forgot to include the "token_type_hint" parameter in the baseline compare (i.e. revocation includes it as optional, introspection does not). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Todd W Lainhart/Lexington/IBM@IBMUS To: "IETF oauth WG" , Date: 03/07/2013 10:17 AM Subject:[OAUTH-WG] draft-richer-oauth-introspection-03 Sent by:oauth-boun...@ietf.org Hi Justin - I'm comparing: http://tools.ietf.org/html/draft-richer-oauth-introspection-03 ...with: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 for symmetry. If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.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
[OAUTH-WG] draft-richer-oauth-introspection-03
Hi Justin - I'm comparing: http://tools.ietf.org/html/draft-richer-oauth-introspection-03 ...with: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 for symmetry. If that's appropriate, and if I use revocation as the baseline, I'm wondering why introspection supports GET in addition to POST, and doesn't require TLS (i.e. revocation only supports POST, and requires TLS). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] A question on token revocation.
> Resource owner needs to know the consumer key (represents the OAuth Client app) & scope to revoke the access token for a given client. I see - you're saying that requiring client credentials on the end point is the problem? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Prabath Siriwardena To: Justin Richer , Cc: "oauth@ietf.org WG" Date: 02/06/2013 10:31 AM Subject:Re: [OAUTH-WG] A question on token revocation. Sent by:oauth-boun...@ietf.org On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer wrote: On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer wrote: These are generally handled through a user interface where the RO is authenticated directly to the AS, and there's not much need for a "protocol" here, in practice. Why do you think leaving access token revocation by RO to a proprietary API is a good practice ? IMO this an essential requirement in API security. I think it makes more sense in the same way that having a "proprietary" UI/API for managing the user consent makes sense: unless you're doing a fully dynamic end-to-end system like UMA, then there's not much value in trying to squeeze disparate systems into the same mold, since they won't be talking to each other anyway. This is required in distributed setup for each API platform from different vendors to perform in an interop manner. And since you refer to it as an "API", what will the RO be using to call this API? Is there a token management client that's separate from the OAuth client? I didn't get your question right... If you meant the how to invoke revocation end point, the the resource owner needs to know the consumer key (represents the OAuth Client app) & scope to revoke the access token for a given client. IMHO token revocation done my RO is more practical than token revocation done by the Client. They're both valid but require different kinds of protocols and considerations. This token revocation draft is meant to solve one problem, and that doesn't mean it can or should solve other seemingly related problems. If you would like to see the RO-initiated token revocation go through (not grant revocation, mind you -- that's related, but different), then I would suggest that you start specifying exactly how that works. I predict it will be problematic in practice, though, as the RO often doesn't actually have direct access to the token itself. Resource owner needs to know the consumer key (represents the OAuth Client app) & scope to revoke the access token for a given client. There are larger applications, like UMA, that have client and PR provisioning that would allow for this to be managed somewhat programmatically, but even in that case you're still generally doing token revocation by a "client" in some fashion. In UMA, though, several different pieces can play the role of a "client" at different parts of the process. Revoking a scope is a whole different mess. Generally, you'd want to just revoke an existing token and make a new authorization grant with lower access if you don't want that client getting that scope anymore. If you just want to downscope for a single transaction, you can already do that with either the refresh token or token chaining approaches, depending on where in the process you are. The latter of these are both client-focused, though, and the RO doesn't have a direct hand in it at this point. Why do you think it a mess. If you revoke the entire token then Client needs to go through the complete OAuth flow - and also needs to get the user consent. If RO can downgrade the scope, then we restrict API access by the client at RS end and its transparent to the client. Downgrading the scope of tokens in the wild is hardly transparent to the client (stuff that it expects to work will suddenly start to fail, meaning that most clients will throw out the token and try to get a new one), and in a distributed system you've got to propagate that change to the RS. If you bake the scopes into the token itself (which many do) then you actually *can't* downgrade a single token, anyway. Yes.. that is the expected behavior. I mean the process is transparent. Client will notice at runtime. Thanks & regards, -Prabath -- Justin Thanks & regards, -Prabath -- Justin On 02/06/2013 04:35 AM, Prabath Siriwardena wrote: I am sorry if this was already discussed in this list.. Looking at [1] it only talks about revoking the access token from the client. How about the resource owner..? There can be cases where resource owner needs to revoke an authorized access token from a given client. Or revoke an scope.. How are we going to address these requirements..? Thoughts appreciated... [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 -- Thanks & Regar
Re: [OAUTH-WG] A question on token revocation.
> If you would like to see the RO-initiated token revocation go through (not grant revocation, mind you -- that's related, but different), then I would suggest that you start specifying exactly how that works. +1 Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Prabath Siriwardena , Cc: "oauth@ietf.org WG" Date: 02/06/2013 10:21 AM Subject:Re: [OAUTH-WG] A question on token revocation. Sent by:oauth-boun...@ietf.org On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer wrote: These are generally handled through a user interface where the RO is authenticated directly to the AS, and there's not much need for a "protocol" here, in practice. Why do you think leaving access token revocation by RO to a proprietary API is a good practice ? IMO this an essential requirement in API security. I think it makes more sense in the same way that having a "proprietary" UI/API for managing the user consent makes sense: unless you're doing a fully dynamic end-to-end system like UMA, then there's not much value in trying to squeeze disparate systems into the same mold, since they won't be talking to each other anyway. And since you refer to it as an "API", what will the RO be using to call this API? Is there a token management client that's separate from the OAuth client? IMHO token revocation done my RO is more practical than token revocation done by the Client. They're both valid but require different kinds of protocols and considerations. This token revocation draft is meant to solve one problem, and that doesn't mean it can or should solve other seemingly related problems. If you would like to see the RO-initiated token revocation go through (not grant revocation, mind you -- that's related, but different), then I would suggest that you start specifying exactly how that works. I predict it will be problematic in practice, though, as the RO often doesn't actually have direct access to the token itself. There are larger applications, like UMA, that have client and PR provisioning that would allow for this to be managed somewhat programmatically, but even in that case you're still generally doing token revocation by a "client" in some fashion. In UMA, though, several different pieces can play the role of a "client" at different parts of the process. Revoking a scope is a whole different mess. Generally, you'd want to just revoke an existing token and make a new authorization grant with lower access if you don't want that client getting that scope anymore. If you just want to downscope for a single transaction, you can already do that with either the refresh token or token chaining approaches, depending on where in the process you are. The latter of these are both client-focused, though, and the RO doesn't have a direct hand in it at this point. Why do you think it a mess. If you revoke the entire token then Client needs to go through the complete OAuth flow - and also needs to get the user consent. If RO can downgrade the scope, then we restrict API access by the client at RS end and its transparent to the client. Downgrading the scope of tokens in the wild is hardly transparent to the client (stuff that it expects to work will suddenly start to fail, meaning that most clients will throw out the token and try to get a new one), and in a distributed system you've got to propagate that change to the RS. If you bake the scopes into the token itself (which many do) then you actually *can't* downgrade a single token, anyway. -- Justin Thanks & regards, -Prabath -- Justin On 02/06/2013 04:35 AM, Prabath Siriwardena wrote: I am sorry if this was already discussed in this list.. Looking at [1] it only talks about revoking the access token from the client. How about the resource owner..? There can be cases where resource owner needs to revoke an authorized access token from a given client. Or revoke an scope.. How are we going to address these requirements..? Thoughts appreciated... [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.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
Re: [OAUTH-WG] How soon until last call on introspection and revocation
>That said, it doesn't mean we can't all just *work* on it... Agreed. Thanks for the clarification. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Hannes Tschofenig , Cc: Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG Date: 02/06/2013 09:57 AM Subject:Re: [OAUTH-WG] How soon until last call on introspection and revocation As editor of introspection draft, I would like to see it become a working group item. After talking with the chairs, there appears to be some friction with the amount of open working items that the working group has right now, though, leading to hesitation to add more to our official plate. That said, it doesn't mean we can't all just *work* on it, and I'm actively editing it based on feedback. We're implementing and deploying it in our own systems right now, too. I'm tracking issues to the draft here if you have any direct changes (or pull requests!): https://github.com/jricher/oauth-spec/issues So I hope that we can at least stabilize the functionality of the spec so that by the time the IETF process can start to chew on it in an official fashion, it will be mostly baked and we can run it through relatively quickly. -- Justin On 02/06/2013 09:45 AM, Hannes Tschofenig wrote: > Hi Todd, > > two answers: > > 1) Token Revocation: > > I had initiated a Working Group Last Call for the token revocation document end of November: > http://www.ietf.org/mail-archive/web/oauth/current/msg10102.html > > As you have seen on the list, this has generated a fair amount of discussion. > > I hope that Torsten, the draft editor, is able to produce a new draft version quickly with a resolution of the open issues that is acceptable to the rest of the group. > > Then, we will have to judge whether the document can move forward to the IESG. > > 2) Introspection > > That document is not even a working group item. > > Ciao > Hannes > > On Feb 6, 2013, at 4:26 PM, Todd W Lainhart wrote: > >> Does anyone have any intuition as to how far away we are on last call for introspection and revocation? > ___ > 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
Re: [OAUTH-WG] How soon until last call on introspection and revocation
Thanks Hannes. > That document is not even a working group item. Ha. I hadn't noticed that - I now see it is part associated to the "Network Working Group" instead of "OAuth Working Group". I'm confused, and perhaps it's just IETF ignorance, or me not paying attention. What does it mean for the introspection spec, which describes itself to be an OAuth 2 endpoint, not to be in this WG? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Hannes Tschofenig To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: Hannes Tschofenig , "IETF oauth WG" Date: 02/06/2013 09:47 AM Subject:Re: [OAUTH-WG] How soon until last call on introspection and revocation Hi Todd, two answers: 1) Token Revocation: I had initiated a Working Group Last Call for the token revocation document end of November: http://www.ietf.org/mail-archive/web/oauth/current/msg10102.html As you have seen on the list, this has generated a fair amount of discussion. I hope that Torsten, the draft editor, is able to produce a new draft version quickly with a resolution of the open issues that is acceptable to the rest of the group. Then, we will have to judge whether the document can move forward to the IESG. 2) Introspection That document is not even a working group item. Ciao Hannes On Feb 6, 2013, at 4:26 PM, Todd W Lainhart wrote: > Does anyone have any intuition as to how far away we are on last call for introspection and revocation? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] How soon until last call on introspection and revocation
Does anyone have any intuition as to how far away we are on last call for introspection and revocation? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] A question on token revocation.
> There can be cases where resource owner needs to revoke an authorized access token from a given client. Why wouldn't the RO go through the client to revoke the token? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Prabath Siriwardena To: "oauth@ietf.org WG" , Date: 02/06/2013 04:36 AM Subject:[OAUTH-WG] A question on token revocation. Sent by:oauth-boun...@ietf.org I am sorry if this was already discussed in this list.. Looking at [1] it only talks about revoking the access token from the client. How about the resource owner..? There can be cases where resource owner needs to revoke an authorized access token from a given client. Or revoke an scope.. How are we going to address these requirements..? Thoughts appreciated... [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.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
Re: [OAUTH-WG] draft-ietf-oauth-revocation
+1 Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: George Fletcher To: Torsten Lodderstedt , Cc: "oauth-boun...@ietf.org" , OAuth WG Date: 02/05/2013 04:35 PM Subject:Re: [OAUTH-WG] draft-ietf-oauth-revocation Sent by:oauth-boun...@ietf.org I'm fine with this solution as well. --George On 2/5/13 3:45 PM, Torsten Lodderstedt wrote: I know, that's why I asked. I think this is the simplest way to deal with this type of error. I therefore prefer it. Am 05.02.2013 um 20:49 schrieb Justin Richer : You know, that works as well. From the client's perspective, the token isn't good anymore. The client shouldn't care if the token was good in the first place if it's revoking it. -- Justin On 02/05/2013 02:41 PM, Torsten Lodderstedt wrote: Why not adopting Bill's suggestion and just return HTTP status code 200 for (already) invalid tokens? regards, Torsten. Am 05.02.2013 um 17:46 schrieb Todd W Lainhart : > Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? I'm not imagining a client doing anything programmatically useful with the distinction. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From:"Richer, Justin P." To:George Fletcher , Cc:OAuth WG Date:02/04/2013 04:10 PM Subject:Re: [OAUTH-WG] draft-ietf-oauth-revocation Sent by:oauth-boun...@ietf.org On Feb 4, 2013, at 3:57 PM, George Fletcher wrote: > > On 2/4/13 3:41 PM, Richer, Justin P. wrote: >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: >> >> >>> - invalid_token error code: I propose to use the new error code "invalid_parameter" (as suggested by Peter and George). I don't see the need to register it (see http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but would like to get your advice. >> something more like "invalid_token_parameter" would maybe make sense, since it's not just *any* parameter, it's the special "token" parameter that we're talking about, but it's distinct from the invalid_token response. The introspection endpoint uses the same pattern of a token= parameter, but since the whole point of the introspection endpoint is determining token validity it doesn't actually throw an error here. >> >> I agree that it doesn't need to be registered (since it's on a different endpoint). > For what it's worth my thinking was that if we have an 'invalid_parameter' error, then the description can define which parameter is invalid. I don't think we should create a bunch of specific error values that are endpoint specific and could overlap which is where the whole error return value started. > Hm, I see what you're saying, but the error response is already endpoint specific. Though there is value in not having conflicting and/or confusing responses from different endpoints that use the same error code for different things. What it really comes down to is: what can the client do with this error? Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? As I'm writing this out, I'm not convinced that it could, really, so this may be a bike shedding argument. -- Justin ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-revocation
> Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? I'm not imagining a client doing anything programmatically useful with the distinction. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: "Richer, Justin P." To: George Fletcher , Cc: OAuth WG Date: 02/04/2013 04:10 PM Subject:Re: [OAUTH-WG] draft-ietf-oauth-revocation Sent by:oauth-boun...@ietf.org On Feb 4, 2013, at 3:57 PM, George Fletcher wrote: > > On 2/4/13 3:41 PM, Richer, Justin P. wrote: >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt wrote: >> >> >>> - invalid_token error code: I propose to use the new error code "invalid_parameter" (as suggested by Peter and George). I don't see the need to register it (see http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but would like to get your advice. >> something more like "invalid_token_parameter" would maybe make sense, since it's not just *any* parameter, it's the special "token" parameter that we're talking about, but it's distinct from the invalid_token response. The introspection endpoint uses the same pattern of a token= parameter, but since the whole point of the introspection endpoint is determining token validity it doesn't actually throw an error here. >> >> I agree that it doesn't need to be registered (since it's on a different endpoint). > For what it's worth my thinking was that if we have an 'invalid_parameter' error, then the description can define which parameter is invalid. I don't think we should create a bunch of specific error values that are endpoint specific and could overlap which is where the whole error return value started. > Hm, I see what you're saying, but the error response is already endpoint specific. Though there is value in not having conflicting and/or confusing responses from different endpoints that use the same error code for different things. What it really comes down to is: what can the client do with this error? Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? As I'm writing this out, I'm not convinced that it could, really, so this may be a bike shedding argument. -- Justin ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-revocation
> Only if it's optional, and informational from the client's behalf. Would you define "access" and "refresh" values here, with a means for other specs (like OIDC) to put in their own values (like "id_token")? I'd also like to see token_type explicitly called out, as we've also extended the spec for a token type. Arguably the type could be encoded in the token itself, but it seems better to not require this of the implementation. That said, the introspection endpoint doesn't disambiguate the incoming token via a token_type parameter. Is there any reason to believe that it wouldn't see the same types of tokens that revocation would? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: "Richer, Justin P." To: Torsten Lodderstedt , Cc: OAuth WG Date: 02/04/2013 03:42 PM Subject:Re: [OAUTH-WG] draft-ietf-oauth-revocation Sent by:oauth-boun...@ietf.org On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt wrote: > Hi all, > > before I publish a new revision of the draft, I would like to sort out the following issues and would like to ask you for your feedback. > > - Authorization vs. access grant vs. authorization grant: I propose to use "authorization grant". +1 to authorization grant > - invalid_token error code: I propose to use the new error code "invalid_parameter" (as suggested by Peter and George). I don't see the need to register it (see http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but would like to get your advice. something more like "invalid_token_parameter" would maybe make sense, since it's not just *any* parameter, it's the special "token" parameter that we're talking about, but it's distinct from the invalid_token response. The introspection endpoint uses the same pattern of a token= parameter, but since the whole point of the introspection endpoint is determining token validity it doesn't actually throw an error here. I agree that it doesn't need to be registered (since it's on a different endpoint). > - Donald F. Coffin raised the need for a token_type parameter to the revocation request. Shall we re-consider this topic? > Only if it's optional, and informational from the client's behalf. Would you define "access" and "refresh" values here, with a means for other specs (like OIDC) to put in their own values (like "id_token")? -- Justin > best regards, > Torsten. > ___ > 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
Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
If we're tallying votes, I'll re-state my position that I'm also in favor of using the scope syntax definition per 6749 - otherwise it is confusing when writing guidance documentation. If supporting JSON array syntax is important for this response value, Don's suggestion of introducing a new response parameter seems a good compromise. From: "Donald F Coffin" To: "'Richer, Justin P.'" , Todd W Lainhart/Lexington/IBM@IBMUS, Cc: "'IETF oauth WG'" , "Anne Hendry" , "Dave Robin" , "Edward Denson" , "John Adkins" , "John Teeter" , "Lynne Rodoni" , "Marty Burns" , , "Ray Perlner" , "Scott Crowder" , "Uday Verma" Date: 02/04/2013 01:56 PM Subject:RE: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax Justin, I am involved with the OpenESPI and OpenADE Task Force within the Smart Grid Interoperability Panel (SGIP) which was established to engage stakeholders from the Smart Grid Community in a participatory public process to identify applicable standards, gaps in currently available standards, and priorities for new standardization activities for the evolving Smart Grid. The SGIP supports the National Institute of Standards and Technology (NIST) in fulfilling its responsibilities under the 2007 Energy Independence and Security Act. My particular function is to chair the OpenESPI OAuth sub-committee which is chartered with the integration of the OAuth 2.0 Protocol and the ESPI Standard. Since OAuth 2.0 (RFC6749) has already established “scope” is a space-separated string, it will be very confusing to implementers to no define “scope” as a JSON array. While a JSON array may be what the current space-separated string is converted into when the application is written using Java or one of its variants, there are other programming languages that implementers may select to use. Having to deal with two methods of handling a “scope” response will require additional logic and merely complicate the coding task. Additional OAuth 2.0 specifications should not redefine data elements that are already defined by RFC6749. Implementers should be able to rely on data element definitions within RFC6749 being persistent throughout the OAuth protocol framework. If the OAuth introspective WG feels “scope” should be a JSON array, then the WG should define a new data element rather than changing the definition of an existing data element already defined by RFC6749. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Monday, February 04, 2013 8:24 AM To: Todd W Lainhart Cc: IETF oauth WG Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax I got the same reading of the list as you, and I could go either way. I believe we absolutely must pick one or the other though. If anyone has thoughts on the matter one way or the other, please speak up. The options are: 1) scopes are returned as a JSON array (current introspection text) 2) scopes are returned as a space-separated string (rfc6749 format for the "scope" parameter) -- Justin On Feb 4, 2013, at 10:06 AM, Todd W Lainhart wrote: Has there been any thinking or movement as to whether the scopes syntax stands as is, or aligns with 6749? Of the folks who chose to respond, it seemed like the position was split. From:Justin Richer To:Todd W Lainhart/Lexington/IBM@IBMUS, Cc:IETF oauth WG Date:01/30/2013 05:34 PM Subject:Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax I should add that this is also a bit of an artifact of our implementation. Internally, we parse and store scopes as collections of discrete strings and process them that way. So serialization of that value naturally fell to a JSON list. -- Justin On 01/30/2013 05:29 PM, Justin Richer wrote: It's not meant to follow the same syntax. Instead, it's making use of the JSON object structure to avoid additional parsing of the values on the client side. We could fairly easily define it as the same space-delimited string if enough people want to keep the scope format consistent. -- Justin On 01/30/2013 05:27 PM, Todd W Lainhart wrote: That the scope syntax in draft-richer-oauth-introspection-01 is different than RFC 6749 Section 3.3, as in: "scope": ["read", "write", "dolphin"], vs. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) Should introspection-01 follow the 6749 syntax for scopes? _
Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
Has there been any thinking or movement as to whether the scopes syntax stands as is, or aligns with 6749? Of the folks who chose to respond, it seemed like the position was split. From: Justin Richer To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG Date: 01/30/2013 05:34 PM Subject:Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax I should add that this is also a bit of an artifact of our implementation. Internally, we parse and store scopes as collections of discrete strings and process them that way. So serialization of that value naturally fell to a JSON list. -- Justin On 01/30/2013 05:29 PM, Justin Richer wrote: It's not meant to follow the same syntax. Instead, it's making use of the JSON object structure to avoid additional parsing of the values on the client side. We could fairly easily define it as the same space-delimited string if enough people want to keep the scope format consistent. -- Justin On 01/30/2013 05:27 PM, Todd W Lainhart wrote: That the scope syntax in draft-richer-oauth-introspection-01 is different than RFC 6749 Section 3.3, as in: "scope": ["read", "write", "dolphin"], vs. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) Should introspection-01 follow the 6749 syntax for scopes? ___ 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
Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
> We should not conflate with OAuth core framework requirements and protected resource requirements. +1 Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Nat Sakimura To: Mike Jones , Cc: "oauth@ietf.org" Date: 01/30/2013 10:00 PM Subject:Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth ) Sent by:oauth-boun...@ietf.org OAuth did not talk make distinctions or talk about HTTP methods because of two reasons: (1) Browser in the middle with HTTP redirect constraint. (2) The protected resource is the party who decides what semantics is being mapped to the HTTP methods. The (1) above is just a work around for the constrained user agents. Registration is server to server, so we do not need to be constrained by this. The (2) is a requirement to the framework because OAuth should not pollute the space and should let the protected resource decide on their own. Registration endpoint is a protected resource that should decide the mapping. We should not conflate with OAuth core framework requirements and protected resource requirements. Nat 2013/1/31 Mike Jones OAuth *never* makes a distinction between what GET and POST do. (Yes, they pass the input parameters differently.) I *really* don?t think we should start doing this now for new operations. It will likely only confuse developers and make things harder for them ? especially when using software that may not always give them full access to all HTTP verbs and header parameters. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, January 30, 2013 6:22 PM To: John Bradley Cc: oauth@ietf.org Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth ) (I changed the subject to match the content.) Right. It does not have to be three endpoints. One endpoint would do (though it depends on how you count the URLs). However, I would do it slightly differently than you (John B.) proposes. As an example, let the registration endpoint be named /clients, which represents the collection of registered clients. (This is the registration endpoint.) Then, POST to the /clients would create the resource in question. (client associate) POST to /clients?client_id=12345 and post params (the resource URL) would update the resource. This is not an idempotent request, and could update any portion of the resource. In particular, client_secret=null or something could mean "rotate secret." GET to /clients?client_id=12345 would return the client registration data. It is idempotent. DELETE to /clients?client_id=12345 would delete the resource. PUT to /clients?client_id=12345 (the resource URL) would replace the resource, and is idempotent. (I am not sure if we need this. Probably better not have one.) For any of the above request except DELETE, the response should return the entire object. (For the purists: Right. This still could be improved by using URI template. The server could publish the server metadata including URI template for the registration etc. At that point, server is freed from forced to use the query parameters. For example, instead of /clients?client_id=12345, it could have instructed the client to use /clients/12345/ or /clients/id/12345 etc. but I think that is going too far.) Nat 2013/1/31 John Bradley That is better, but I don't see an advantage to that over using a query parameter. They are equally restful or not as the case may be. To be more restful I think you want a single endpoint using HTTP verbs. POST /reg_endpoint?paramaters ? -> register PUT /reg_endpoint?client_id=12345¶maters -> update PUT /reg_endpoint?client_id=12345&rotate_secret=true The downside is developers understanding On 2013-01-30, at 1:17 PM, Justin Richer wrote: > > On 01/30/2013 10:55 AM, John Bradley wrote: >> My feeling was that letting the registration endpoint be a single URL (any url) and using query paramaters was easer for servers and clients. >> >> Saying take the base URI for the registration endpoint and append these paths to it to do different operations seems more likely to go wrong fro developers. > Right, and to clarify, this isn't what I was saying. The spec wouldn't specify the path at all, just say that they're three different endpoint URLs. The same way that we specify that the auth endpoint and token endpoint are different URLs. > > I think my example might have been misleading. The URLs could just as easily be: > > client_register -> /register_a_new_client > rotate_secret -> /client/go_get_a_secret_or_something > client_update-> /maintenance/update_client_information > > > >> >> Allowing both bath and query parameters is the worst option. >> >> I am sympathetic with using POST and PUT
Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
We implemented our dynamic client registration along the lines that Nat describes, except that the resource segment and not the query parm identifies the client. The POST and the GET on the collection return the resource identifiers (HATEOS). Query parms on the collection GET works as you might imagine. There's a lot of precedent for this style of CRUD programming - I'd be surprised if developers didn't get the pattern, and expected consistency with OAuth authz programming. I'm not manipulating resources when I'm hitting OAuth endpoints. Create a client: - POST /example/clients HTTP/1.1 Host: example.com:9443 Content-Length: 494 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 client_name=My%20App&... Fetch a single client: -- GET /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1 Fetch all clients: -- GET /example/clients HTTP/1.1 Modify a client: -- PUT /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1 Host: example.ibm.com:9443 Content-Type: application/json;charset=UTF-8 If-Match: "osQf9mPplNvituLylwpDmQ==" Content-Length: 217 Delete a client: DELETE /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1 Host: example.ibm.com:9443 If-Match: "osQf9mPplNvituLylwpDmQ==" Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Nat Sakimura To: John Bradley , Cc: oauth@ietf.org Date: 01/30/2013 09:22 PM Subject:[OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth ) Sent by:oauth-boun...@ietf.org (I changed the subject to match the content.) Right. It does not have to be three endpoints. One endpoint would do (though it depends on how you count the URLs). However, I would do it slightly differently than you (John B.) proposes. As an example, let the registration endpoint be named /clients, which represents the collection of registered clients. (This is the registration endpoint.) Then, POST to the /clients would create the resource in question. (client associate) POST to /clients?client_id=12345 and post params (the resource URL) would update the resource. This is not an idempotent request, and could update any portion of the resource. In particular, client_secret=null or something could mean "rotate secret." GET to /clients?client_id=12345 would return the client registration data. It is idempotent. DELETE to /clients?client_id=12345 would delete the resource. PUT to /clients?client_id=12345 (the resource URL) would replace the resource, and is idempotent. (I am not sure if we need this. Probably better not have one.) For any of the above request except DELETE, the response should return the entire object. (For the purists: Right. This still could be improved by using URI template. The server could publish the server metadata including URI template for the registration etc. At that point, server is freed from forced to use the query parameters. For example, instead of /clients?client_id=12345, it could have instructed the client to use /clients/12345/ or /clients/id/12345 etc. but I think that is going too far.) Nat 2013/1/31 John Bradley That is better, but I don't see an advantage to that over using a query parameter. They are equally restful or not as the case may be. To be more restful I think you want a single endpoint using HTTP verbs. POST /reg_endpoint?paramaters ? -> register PUT /reg_endpoint?client_id=12345¶maters -> update PUT /reg_endpoint?client_id=12345&rotate_secret=true The downside is developers understanding On 2013-01-30, at 1:17 PM, Justin Richer wrote: > > On 01/30/2013 10:55 AM, John Bradley wrote: >> My feeling was that letting the registration endpoint be a single URL (any url) and using query paramaters was easer for servers and clients. >> >> Saying take the base URI for the registration endpoint and append these paths to it to do different operations seems more likely to go wrong fro developers. > Right, and to clarify, this isn't what I was saying. The spec wouldn't specify the path at all, just say that they're three different endpoint URLs. The same way that we specify that the auth endpoint and token endpoint are different URLs. > > I think my example might have been misleading. The URLs could just as easily be: > > client_register -> /register_a_new_client > rotate_secret -> /client/go_get_a_secret_or_something > client_update-> /maintenance/update_client_information > > > >> >> Allowing both bath and query parameters is the worst option. >> >> I am sympathetic with using POST and PUT and perhaps GET but I worry about OAuth developers not getting it. >> >> I also don't get Tony's point about multi tenancy. If each tenant can have there own registration endpoint I don't see a problem beyond finding the endpoint and that is what we have WF for. > Exactly. And to Bill's poin
Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
I would vote for consistency with 6749 - string tokenizing doesn't seem like a big deal, esp. since clients are going to have to deal with it when scopes are returned from the token endpoint. It was raised here when I realized that we would have to give clients two types of guidance when dealing with scopes in the introspection response and 6749 endpoints. If the thinking is that 6749 got it wrong (didn't use JSON syntax appropriately), and this is getting it right, that's fine. I'm more interested in knowing if the community thinks it's going to change. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Justin Richer To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG Date: 01/30/2013 05:29 PM Subject:Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax It's not meant to follow the same syntax. Instead, it's making use of the JSON object structure to avoid additional parsing of the values on the client side. We could fairly easily define it as the same space-delimited string if enough people want to keep the scope format consistent. -- Justin On 01/30/2013 05:27 PM, Todd W Lainhart wrote: That the scope syntax in draft-richer-oauth-introspection-01 is different than RFC 6749 Section 3.3, as in: "scope": ["read", "write", "dolphin"], vs. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) Should introspection-01 follow the 6749 syntax for scopes? ___ 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-WG] draft-richer-oauth-introspection-01 scope syntax
That the scope syntax in draft-richer-oauth-introspection-01 is different than RFC 6749 Section 3.3, as in: "scope": ["read", "write", "dolphin"], vs. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) Should introspection-01 follow the 6749 syntax for scopes? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Best practices on client_id
There can't be any security requirements for the client_id - it serves to identify both public and confidential clients. It's only requirement be that it be a unique identifier (across public and confidential clients) in the domain of clients that the AS serves. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Antonio Tapiador del Dujo To: "oauth@ietf.org" , Date: 01/25/2013 09:09 AM Subject:[OAUTH-WG] Best practices on client_id Sent by:oauth-boun...@ietf.org Are there any recommendations for the authorization server when generating a client_id. Any security consideration? Should the client_id be a random string or it is save being just the database primary key? Kind regards. ___ 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-WG] Question on the definition of an authorization endpoint response_type extension
I've defined a new response_type for the authorization endpoint for dealing with sessions - call it "urn:example:session_code". Am I required to also include that value in the response as the code identifier, as in (unencoded): https://client.example.com/cb?urn:example:session_code=SplxlOBeZQQYbYS6WxSbIA &state=xyz I can see arguments either way (returning "code" or "urn:example:session_code" as a response parameter) but I'm not finding guidance in 6749. Also, I'm unsure if questions like this are appropriate for this mailing list's charter, or are best directed to stackoverflow. thanks -- Todd ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerning OAuth introspection
> On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture. +1 -- Todd From: Eve Maler To: Sergey Beryozkin , Cc: Paul Bryan , "oauth@ietf.org WG" Date: 01/23/2013 12:18 PM Subject:Re: [OAUTH-WG] Concerning OAuth introspection Sent by:oauth-boun...@ietf.org Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture. If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used: http://tools.ietf.org/html/draft-pbryan-http-json-resource-03 With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction. Eve On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin wrote: > On 23/01/13 15:47, Justin Richer wrote: >> Which brings up an interesting question for the Registration doc: right >> now, it's set up as a single endpoint with three operations. We could >> instead define three endpoints for the different operations. >> >> I've not been keen to make that deep of a cutting change to it, but it >> would certainly be cleaner and more RESTful API design. What do others >> think? >> > IMHO the purity should be balanced against the practicality/simplicity > of the implementation. > Talking about 3 endpoints at the spec level may be treated as the exact > requirement to have 3 separate application endpoints for the single type > of activity, the registration. Can the spec be re-worded such that > "resources" are used instead of endpoints or similar, example, "resource > available at /a will support the following, at /b - something else", or > may be something similar, thus it will read better too from the design > point of view, and let implementers to use 1 endpoint or 3 ones, > whichever way they prefer it > > Thanks, Sergey > >> -- Justin >> >> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>> >>> =nat via iPhone >>> >>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>> (CC'ing the working group) I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. -- Justin On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: > Justin, > > This spec is looking good.. > > One thing I would like to recommend is to add "action"/"operation" to the request. (and potentially add client_id and client_secret) > > So the request will be like : > token REQUIRED > operation (wording to be determine) OPTIONAL inquire (default) | revoke ... > resource_idOPTIONAL > client_id OPTIONAL > client_secret OPTIONAL > > And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). > > Please consider. > > ShiuFun > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ 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
Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty?
Hi Hannes - Providing localization support indirectly via the error_uri was the conclusion that we were coming to, so thanks for responding and confirming that. Best wishes -- Todd Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Hannes Tschofenig To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: Hannes Tschofenig , oauth@ietf.org, oauth-boun...@ietf.org Date: 01/18/2013 04:42 AM Subject:Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty? Hi Todd, it is important to note that the error_description is not meant to be shown to the end users. That was the reason for not introducing internationalization support. If you want to provide some additional information about the error description in other languages I would suggest to use the error_uri to point the developer to that information. Ciao Hannes On Jan 17, 2013, at 8:09 PM, Todd W Lainhart wrote: > We're working on an OAuth 2.0 AS, with extensions defined for session mgmt. We're trying to adopt uniformly the error reporting mechanism in 6749. > > I'm now realizing that the error_description response in specified to be USASCII. I was assuming that the error message could be UTF-8 encoded, such that I could return error messages in the client's locale. E.G. consider the client credentials grant. The store on the AS holding the registration is down, so I'd like to return a 500 with an error message from the store, from a catalog mapped to the client's language. > > I've wondered about adding an additional response parameter, something like error_description_locale, but thought that there might be better practices out there. I'm also wondering about the USASCII constraint on error_description. I'm a long-time reader of this list, but I'm not recalling the background on this. > > > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250 > 1-978-899-4705 > 2-276-4705 (T/L) > lainh...@us.ibm.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
[OAUTH-WG] error_description USASCII-encoded - is this a difficulty?
We're working on an OAuth 2.0 AS, with extensions defined for session mgmt. We're trying to adopt uniformly the error reporting mechanism in 6749. I'm now realizing that the error_description response in specified to be USASCII. I was assuming that the error message could be UTF-8 encoded, such that I could return error messages in the client's locale. E.G. consider the client credentials grant. The store on the AS holding the registration is down, so I'd like to return a 500 with an error message from the store, from a catalog mapped to the client's language. I've wondered about adding an additional response parameter, something like error_description_locale, but thought that there might be better practices out there. I'm also wondering about the USASCII constraint on error_description. I'm a long-time reader of this list, but I'm not recalling the background on this. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials
Although it seems like an abuse of the protocol, I'm wondering at Draft 22
as a mechanism for providing authorization without specifying client
credentials (i.e. evaluating it as part of an SSO solution).
Specifically, I'm referencing the scenario/flow in Section 4.3 ("Resource
Owner Password Credentials") where a callback_uri parameter is not
specified. Assume that the client type is "public".
I'm also referencing Section 2.4, "Unregistered Clients", where the text
says that the spec does not exclude the use of unregistered clients (with
the appropriate disclaimers).
Under these conditions then, can I then expect a spec-compliant
authorization server to not require client credentials when requesting an
access token?
-- Todd
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] VOTE: Token type response parameter
#3 Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Eran Hammer-Lahav To: OAuth WG Date: 11/18/2010 02:50 AM Subject: Re: [OAUTH-WG] VOTE: Token type response parameter Sent by: oauth-boun...@ietf.org Nothing? No one cares? EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, November 16, 2010 5:33 PM > To: OAuth WG > Subject: [OAUTH-WG] VOTE: Token type response parameter > > The new draft will include a new token_type response parameter. In my > original proposal I suggested making this an optional response parameter > with a default value of 'bearer' or 'plain' to keep existing -10 implementation > compliant with -11. > > Options are: > > 1. Missing type response parameter means bearer token 2. Missing type > response parameter means whatever the service default token type is 3. > Servers must include an explicit token type with each response, where each > token spec (bearer, signed, etc.) register their own type name 4. No token > type. Type is determined by other attributes (such as secret and hash > algorithm name). > > #1 and #3 are the most consistent with current design and best for interop. > #1 requires no changes to -10 code, but leads to ugly spec organization (it > links the bearer token spec with the framework spec). > > I'm strongly in favor of #3 as existing clients will ignore this and just assume > bearer. Any server introducing a new token type will need to change clients > anyway. Servers will need to be changed to add the new parameter but > that's a trivial change (and -11 includes some normative changes already - all > minor). > > So +1 on #3 for me. > > Please register your preference. > > EHL > ___ > 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
