Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Why RO as an issuer is only theoretical today? Brian Campbell 2012-12-04 23:41 收件人 Nat Sakimura 抄送 zhou.suj...@zte.com.cn, "oauth@ietf.org" 主题 Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? The intent was definitely not to constrain who/what could be the issuer. But also try to provide some guidance around the common cases that are actually being deployed now, which are the client self-issued and STS variants. Resource owner as an issuer is an interesting case but seems mostly theoretical at this point. I feel like mentioning the resource owner there in §5.1 would cause more confusion than anything else. I'd prefer to just strike the whole sentence in question and maybe add some additional text to §3 that clarifies that the issuer can really be any entity, if folks think a change is needed here? On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura wrote: Actually, "The issuer may be either an OAuth client (when assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. " is not really clean. OAuth client is just another example of an issuer. So, perhaps the sentence could be: "Example of issuers include an OAuth client, resource owner, an independent third party." So, the clause becomes: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. Example of issuers include an OAuth client, resource owner, an independent third party. Nat Nat On Tue, Dec 4, 2012 at 11:40 AM, wrote: Chuck Mortimore 写于 2012-12-04 10:26:50: > Please feel free to suggest better language. > > Issuer simply allows the token service to know who created the > assertion, so it can look them up and see if they're trusted. > Effectively the same as an Issuer in SAML. a conflict : "The token service is the assertion issuer" in assertion document. while you said "token service know who created the assertion" I wonder if the following text is acceptable: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. The issuer may be either an OAuth client (when assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. 6.3. Client Acting on Behalf of a User The Issuer of the assertion MUST identify the entity that issued the assertion as recognized by the Authorization Server. If the assertion is self-issued, the Issuer SHOULD be the "client_id". If the assertion was issued by a Security Token Service (STS), the Issuer SHOULD identify the STS as recognized by the Authorization Server.If the assertion was issued by the resource owner, the Issuer SHOULD identify the resource owner as recognized by the Authorization Server. > > -cmort > > On Dec 3, 2012, at 6:23 PM, wrote: > > > Obviously, it is not so clear from the language there. > > > Chuck Mortimore 写于 2012-12-04 10:17:12: > > > There's no reason why it can't be resource owner today. > > > > On Dec 3, 2012, at 6:06 PM, < zhou.suj...@zte.com.cn > > > wrote: > > > > > > +1. > > And why it was not looked at that time? > > > > oauth-boun...@ietf.org 写于 2012-12-04 01:30:55: > > > > > Actually, I think it is a good time to start looking at the resourse > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had brought > > > this up a couple of years ago.) > > > > > > Igor > > > > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: > > > I suppose, yes. I was reading it like that all the time. > > > Whether it is or not, if it is still ok, it might be better to > clarify it. > > > Word like "third party" tends to be a bit of problem without > > clearlydefining. > > > I had similar experience in other fora. > > > > > > Nat > > > > > > Sent from iPad > > > > > > 2012/12/03 0:52、"zhou.suj...@zte.com.cn" の > > > メッセージ: > > > > > > > > could be Resource owner? > > > > > > > > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" > > > 发件人: oauth-boun...@ietf.org > > > 2012-12-03 16:49 > > > > > > 收件人 > > > > > > "ext Nat Sakimura" , "Brian Campbell" < > > > bcampb...@pingidentity.com>, "oauth" > > > > > > 抄送 > > > > > > 主题 > > > > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be > > > either the client or a third party token service? > > > > > > > > > > > > > > > Hi Nat, > > > > > > The current text essentially says that the assertion can either be > > > created by the client (in which case it is self-signed) or it can be > > > created by some other entity (which is then called the third party > > > token service). So, this third party could be the authorization server. > > > > > > Ciao > > > Hannes
[OAUTH-WG] Redirection flows, pre-authorized tokens and client-requested scopes
We are working with one of our users on the support for pre-authorized tokens which can be checked by AS at the initial end user redirection to this AS before requesting the end-user authorization. My assumption is that if the pre-authorized token exists then the client provided scope, if any, is basically ignored, because the end user has already pre-authorized a given client with a specific token which will have a scope set as requested by the end user at the pre-authorization time. Is that right ? IMHO yes and the best AS can do in this case is simply log what scope the client is actually requesting but reply with the token containing the pre-authorized scope, please correct me if not thanks, Sergey ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
You're right that UMA bundles several things in the protection API (covered by the protection scope, whose keyword is actually the resolvable URI "http://docs.kantarainitiative.org/uma/scopes/prot.json";). One of those things is the use of the token status endpoint; the rest is the whole mechanism for outsourcing protection. Maybe it makes sense for us to define "protection" as a superset scope that includes a smaller scope of "introspection", which would map to using the introspection endpoint being defined in your spec. What do you think? The permissions that get returned as the result of UMA-style introspection are actually part of the definition of the "bearer" UMA token profile. Other token contents could be profiled specifically for use with UMA, or we could perhaps also reuse OAuth token profiles. The wrapper being defined in your spec for totally generic token metadata seems like a good idea; the innards could be any number of things (with their own unique metadata), such as policy yes/no decisions, the claims gathered, etc. This topic is discussed in the latter part of this slide deck: http://kantarainitiative.org/confluence/download/attachments/17760302/UMA+and+XACML+2012-10-18.pdf Thanks! Eve On 30 Nov 2012, at 7:56 AM, Justin Richer wrote: > Hi Eve, > > Yes, you've got the right idea. In a lot of cases that we're dealing with, > the relationship between the RS and AS is set up ahead of time. So the RS > knows which AS to ask, and the AS knows how to deal with the different RS's > it cares about. UMA gives you a nice dynamic way to introduce the two, but I > think that the introduction should be a separate step from the query, since > both parts are reusable independently. > > Correct me if I'm wrong, but UMA also has the whole API for returning > permissions associated with a token, beyond just the simple current-status > message, right? Even so, I think it makes sense to decide on what the core > set of info that would come back from such a token introspection would be, > and what it means. Different types of tokens (Bearer, MAC, HOK) are going to > have different types of metadata associated with them, probably, but there > are a few core pieces (expiration, scopes) that would be common and useful. > > -- Justin > > On 11/29/2012 05:59 PM, Eve Maler wrote: >> Hi Justin-- Glad to see this moving forward. This draft seems pretty >> straightforward, and I imagine the UMA core spec could probably incorporate >> a reference out to this rather than continuing to use our custom-specified >> method for what we'd called "token status". I wanted to highlight a couple >> of things we've defined beyond what you have here, in case they're of >> interest to the wider community. >> >> This spec defines what I'd call "shallow AS/RS communication", in that it >> assumes a trust relationship and context that's set up between them >> completely out of band. UMA needed "deep AS/RS communication", which allows >> for them to live in separate domains, potentially run by disparate parties. >> (This is akin to the separation in OpenID Connect of IdPs and third-party >> claim providers, and I've heard of a number of use cases now for the same >> separation in plain OAuth.) Thus, we defined a means by which the AS and RS >> could be introduced -- it's actually just an embedded OAuth flow -- so that >> your mention of a "separate OAuth2 Access Token" option in Section 2.1 is >> dictated in UMA to be an OAuth token, with a particular scope covering the >> use of the token introspection endpoint. >> >> The API exposed by the AS (in UMA, an "authorization manager" or AM) that >> includes usage of the token introspection endpoint is called a "protection >> API", and it includes registration of information about protected resources >> so that the AS can manage the issuance of tokens that it will later be asked >> to introspect. >> >> Finally, UMA has a simple extension point, called "UMA token profile", >> defined in its (JSON-encoded) AM config data that allows the content >> associated with the token to be standardized. Actually it dictates more than >> the content; there are protocol aspects to it too, perhaps akin to OAuth's >> token profiles. >> >> If there's interest in sedimenting some of these pieces into the OAuth >> layer, we'd certainly be interested to carve out modules (where possible) >> and submit them for consideration. Note that all of these features are >> present in our http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 >> submission. >> >> Thanks, >> >> Eve >> >> On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." wrote: >> >>> I took some time this morning to put together a draft of Token >>> Introspection. This is largely based on how we implemented it here a few >>> years ago, and I'm hoping that this and the Ping draft can help move the >>> conversation about introspection forward. >>> >>> -- Justin >>> >>
Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
Hi Justin-- Glad to see this moving forward. This draft seems pretty straightforward, and I imagine the UMA core spec could probably incorporate a reference out to this rather than continuing to use our custom-specified method for what we'd called "token status". I wanted to highlight a couple of things we've defined beyond what you have here, in case they're of interest to the wider community. This spec defines what I'd call "shallow AS/RS communication", in that it assumes a trust relationship and context that's set up between them completely out of band. UMA needed "deep AS/RS communication", which allows for them to live in separate domains, potentially run by disparate parties. (This is akin to the separation in OpenID Connect of IdPs and third-party claim providers, and I've heard of a number of use cases now for the same separation in plain OAuth.) Thus, we defined a means by which the AS and RS could be introduced -- it's actually just an embedded OAuth flow -- so that your mention of a "separate OAuth2 Access Token" option in Section 2.1 is dictated in UMA to be an OAuth token, with a particular scope covering the use of the token introspection endpoint. The API exposed by the AS (in UMA, an "authorization manager" or AM) that includes usage of the token introspection endpoint is called a "protection API", and it includes registration of information about protected resources so that the AS can manage the issuance of tokens that it will later be asked to introspect. Finally, UMA has a simple extension point, called "UMA token profile", defined in its (JSON-encoded) AM config data that allows the content associated with the token to be standardized. Actually it dictates more than the content; there are protocol aspects to it too, perhaps akin to OAuth's token profiles. If there's interest in sedimenting some of these pieces into the OAuth layer, we'd certainly be interested to carve out modules (where possible) and submit them for consideration. Note that all of these features are present in our http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission. Thanks, Eve On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." wrote: > I took some time this morning to put together a draft of Token Introspection. > This is largely based on how we implemented it here a few years ago, and I'm > hoping that this and the Ping draft can help move the conversation about > introspection forward. > > -- Justin > > Begin forwarded message: > >> From: >> Subject: New Version Notification for draft-richer-oauth-introspection-00.txt >> Date: November 27, 2012 1:44:01 PM EST >> To: >> >> >> A new version of I-D, draft-richer-oauth-introspection-00.txt >> has been successfully submitted by Justin Richer and posted to the >> IETF repository. >> >> Filename: draft-richer-oauth-introspection >> Revision: 00 >> Title: OAuth Token Introspection >> Creation date: 2012-11-27 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: >> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >> Htmlized: >> http://tools.ietf.org/html/draft-richer-oauth-introspection-00 >> >> >> Abstract: >> This specification defines a method for a client or protected >> resource to query an OAuth authorization server to determine meta- >> information about an OAuth token. >> >> >> >> >> >> The IETF Secretariat >> > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth 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
Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
Preparing generically for context to be provided by the RS/host, as well as metadata provided back by the AS/AM, seems like a good idea, and hopefully doesn't have to be over-complex. Extension points can be quite simple if designed right. But I agree that the basic use case of "give me back the info about this token" should be nice and clean. Eve On 30 Nov 2012, at 11:48 AM, Justin Richer wrote: > I think this approach makes sense and it gels with the basic concept that I'd > had about the response from the introspection endpoint being extensible and, > at some level, service specific. An interesting question then is do we want > to have some kind of signaling from the client as to what they want or need > back? In other words, make it into a full query API as opposed to a single > callback. UMA starts to do this, with fields for the resource_set_id and > host_id as part of the request. The pattern that I had written would have > implicitly tied the "resource set id" to whatever client credentials were > being used to make the request, but we already have potential use cases here > (not implemented yet) of the RS wanting to provide more context to the > authorization server. One of these would be passing along the user's OIDC > id_token in addition to their access_token to help make auth decisions. > > All of that's very quickly going down the road to complexity that might crowd > out the simple case, though, so my gut instinct is to avoid it in the core > spec. Still, it's something to consider, especially if UMA wants to be > wrapped using generic introspection, and the right level of complexity in the > core could make the future much simpler. > > But even so, I think the simple case of "I have a token and want to know > about it" needs to be supported without extra scaffolding. > > -- Justin > \ 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-WG] My earlier comments on the dyn client reg draft
Hannes suggested that, for transparency, I should share with the list the comments that I had earlier sent to Justin. Here they are. I believe these have all been addressed in one way or another by now. Eve General - Authorship: I suspect that Christian Scholz really won't mind if you move him to the acknowledgments. He actually had not that much to do with the original UMA-based draft, but was our official spec editor of the group at the time. (I wrote the bulk of the requirements, and Maciej wrote the bulk of the request/response stuff.) 1. Introduction - Para 2: s/meta information/metadata/ to match other references. 2.1. Client Association Request - Could you make it a bit clearer that the parameters you list are actually defined in Section 3? I found this confusing at first. 2.2. Client Association Response (and following) - Is it worthwhile defining a media type application/json+something for the various JSON-encoded responses defined in the doc? I'm not sure if the OAuth spec has been going to this trouble. The UMA spec does -- which means that eventually we'll have to submit to IANA for registering those types... - client_secret: s/us used/is used/ s/not required/OPTIONAL/ ? - registration_access_token: Is there any reason not to call this simple "access_token"? 2.3. Client Update Request - Para 1: Why is the empty-value interpretation a SHOULD rather than a MUST? It would seem that we'd want interoperability in how to replace/wipe metadata. 2.4. Client Update Response (and following) - For client_id in responses, does it make sense to say something like "A unique Client Identifier matching the one in the request"? 2.5. Rotate Secret Request - Having it be an error if the client never originally had a secret, and the question about rotating the access token, makes me think that we should keep things as simple as possible, and make this operation be something like "client_refresh", which always refreshes the access token and -- if it was issued a secret -- the secret as well? There's sort of a recursiveness to managing meta-secrets used to issue client identities, and the last thing we want is to embed a full-blown OAuth mechanism that makes it token turtles all the way down... 2.7. Client Registration Error Response - Trying to think of additional error conditions: invalid ID? Invalid token? These don't seem covered by the existing options. Of course, it's possible this detail shouldn't be exposed in the error response for security reasons. 3. Client Metadata - In "token_endpoint_auth_method": Is "unspecified or omitted" redundant? What's the difference? 5. Security Considerations - I assume that, eventually, the RP/IdP language from the OpenID Connect draft will need to be genericized. 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-WG] OAUTH Conference Call Dec 14th, 2012 (was Re: OAuth WG Virtual Interim Meetings, 11 January 2013 & 21 January 2013)
FYI, We will also be holding a conference call on Friday, December 14th at 1pm EST. This call is not an official virtual interim meeting which means no decisions can be made, but it is a time where we plan to discuss progress and discuss any open issues. We will send out dial-in information ASAP. Thanks, -derek, wg co-chair IESG Secretary writes: > The OAuth Working Group will hold virtual interim meetings as follows: > > * 11th January 2013, 1pm EST > * 21st January 2013, 1pm EST > > Agenda and dial-in information will be posted on the OAuth mailing list > (http://www.ietf.org/mail-archive/web/oauth/current/maillist.html) prior > to the meetings. > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
The intent was definitely not to constrain who/what could be the issuer. But also try to provide some guidance around the common cases that are actually being deployed now, which are the client self-issued and STS variants. Resource owner as an issuer is an interesting case but seems mostly theoretical at this point. I feel like mentioning the resource owner there in §5.1 would cause more confusion than anything else. I'd prefer to just strike the whole sentence in question and maybe add some additional text to §3 that clarifies that the issuer can really be any entity, if folks think a change is needed here? On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura wrote: > Actually, "The issuer may be either > an OAuth client (when assertions are self-issued) or any other > entity, e.g., a third party > token service, resource owner. " is not really clean. > > OAuth client is just another example of an issuer. > > So, perhaps the sentence could be: > > "Example of issuers include an OAuth client, resource owner, an > independent third party." > > So, the clause becomes: > > Issuer The unique identifier for the entity that issued the > assertion. Generally this is the entity that holds the key > material used to generate the assertion. >Example of issuers include an OAuth client, resource owner, an > independent third party. > > Nat > > Nat > > On Tue, Dec 4, 2012 at 11:40 AM, wrote: > >> >> >> >> Chuck Mortimore 写于 2012-12-04 10:26:50: >> >> >> > Please feel free to suggest better language. >> >> > >> > Issuer simply allows the token service to know who created the >> > assertion, so it can look them up and see if they're trusted. >> > Effectively the same as an Issuer in SAML. >> >> a conflict : "The token service is the assertion issuer" in assertion >> document. >> while you said "token service know who created the assertion" >> >> I wonder if the following text is acceptable: >> >> Issuer The unique identifier for the entity that issued the >> assertion. Generally this is the entity that holds the key >> material used to generate the assertion. The issuer may be either >> an OAuth client (when assertions are self-issued) or any other >> entity, e.g., a third party >> token service, resource owner. >> >> >> 6.3. Client Acting on Behalf of a User >> >> The Issuer of the assertion MUST identify the entity that issued >> the assertion as recognized by the Authorization Server. If the >> assertion is self-issued, the Issuer SHOULD be the "client_id". >> If the assertion was issued by a Security Token Service (STS), the >> Issuer SHOULD identify the STS as recognized by the Authorization >> Server.If the assertion was issued by the resource owner, the >> Issuer SHOULD identify the resource owner as recognized by the >> Authorization >> Server. >> >> > >> > -cmort >> > >> > On Dec 3, 2012, at 6:23 PM, wrote: >> > >> > >> > Obviously, it is not so clear from the language there. >> > >> > >> > Chuck Mortimore 写于 2012-12-04 10:17:12: >> > >> > > There's no reason why it can't be resource owner today. >> > > >> > > On Dec 3, 2012, at 6:06 PM, < >> zhou.suj...@zte.com.cn >> > > > wrote: >> > > >> > > >> > > +1. >> > > And why it was not looked at that time? >> > > >> > > oauth-boun...@ietf.org 写于 2012-12-04 01:30:55: >> > > >> > > > Actually, I think it is a good time to start looking at the resourse >> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had >> brought >> > > > this up a couple of years ago.) >> > > > >> > > > Igor >> > > > >> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: >> > > > I suppose, yes. I was reading it like that all the time. >> > > > Whether it is or not, if it is still ok, it might be better to >> > clarify it. >> > > > Word like "third party" tends to be a bit of problem without >> > > clearlydefining. >> > > > I had similar experience in other fora. >> > > > >> > > > Nat >> > > > >> > > > Sent from iPad >> > > > >> > > > 2012/12/03 0:52、"zhou.suj...@zte.com.cn" の >> > > > メッセ�`ジ: >> > > >> > > > >> > > > could be Resource owner? >> > > > >> > > >> > > > >> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" >> > > > 发件人: oauth-boun...@ietf.org >> > > > 2012-12-03 16:49 >> > > > >> > > > 收件人 >> > > > >> > > > "ext Nat Sakimura" , "Brian Campbell" < >> > > > bcampb...@pingidentity.com>, "oauth" >> > > > >> > > > 抄送 >> > > > >> > > > 主题 >> > > > >> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be >> > > > either the client or a third party token service? >> > > > >> > > > >> > > > >> > > > >> > > > Hi Nat, >> > > > >> > > > The current text essentially says that the assertion can either be >> > > > created by the client (in which case it is self-signed) or it can be >> > > > created by some other entity (which is then called the third party >> > > > token service). So, this third party could be the authorization >> server. >> > > > >> > > > Ciao >> > > > Hann
