Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Eve, A number of us want to hold a session on the Tuesday of IIW to discuss the various options, that people have built. UMA is one of the more advanced ones, but we also have Ping, MITRE, AOL, and others. There is a fair amount of overlap between them. If the AS RS work is not included in the charter it will probably continue independently until the next rechartering. John B. On 2012-04-22, at 5:43 PM, Eve Maler wrote: Once again, you may want to look at the UMA core I-D to see how it defines an AS/RS interface: http://tools.ietf.org/html/draft-hardjono-oauth-umacore-04 (see particularly Section 3.3) It uses what is by now a very common token introspection pattern to have the RS get the AS's crucial help in validating the token that was presented to it. UMA has a mandatory-to-implement token profile called bearer, which treats the token introspection endpoint as a run-time way to get the content associated with the token blob. Obviously, what's returned from that call is currently UMA-specific (and in fact this class of profiles is called UMA token profiles). Note that the call to the token introspection endpoint must be accompanied by an OAuth token in the header because the endpoint is OAuth-protected. (Yes, it's turtles all the way down...) We haven't yet defined an UMA JWT token profile, but that's the next logical step. This type of introspection functionality could be called a narrow definition of the AS/RS interface requirement. To make it possible to have the AS and RS live in completely separate domains potentially controlled by different parties (a broad definition), a number of other elements would ultimately be required. This is where UMA's entire protection API may be interesting to look at, since it has been demonstrated to apply to typical OAuth use cases (single resource owner) as well as access management use cases (resource owner and requesting party are different). Eve On 19 Apr 2012, at 11:31 AM, Torsten Lodderstedt wrote: Hi Justin, In my opinion, the OpenID Connect introspection/checkid endpoint is a convenience function for clients (not resource servers) unable to decrypt id tokens and validate their signatures. I'm not convinced this function is needed, that's why I proposed to drop it. The AS-PR endpoint servers a different purpose, as it allows to implement handle-based token designs. The AS just creates simple token (e.g. a random number), which is very small and does not need to be encrypted or signed. This might result in simple designs. On the other hand, the PR needs to lookup authz data as part of the request implementation, which might have a negative impact on performance and scalability. That's where self-contained tokens, such as JWT have their merits. I don't think one would combine self-contained tokens with an AS-PR endpoint. Or is this the case in any existing implementations? The point I wanted to make is: no matter how the resource server acquires authz data (as token content/JWT or via request to another AS-PR endpoint), the authz data will be the same. And as part of the JWT standardization, we will identify this data and specify a JSON format to represent it. The same representation could be used at the AS-PR endpoint as well. regards, Torsten. Am 18.04.2012 22:23, schrieb Justin Richer: I think we might be crossing wires about input to the token introspection endpoint vs. output from it. In OpenID Connect, you send a JWT in, and get back a JSON object that represents the Claims bit of the JWT. In our implementation (and I think both Ping and AOL's), you send in an arbitrary token (with no proscribed format) and get back a JSON object with different pieces in it. Ours included a list of scopes and an expiration timestamp, others did different things, like audience and issuer, as part of the return. The point I was trying to make is that the information returned from the AS-PR interface isn't necessarily embedded inside of the token used to call that interface. In OpenID Connect, it is, and the CheckID endpoint just unwraps the JWT for you. In the larger case, what's really going on is that the PR presents a token that it's not sure what it's good for and gets back something that answers that question. Since a JWT Claims section can be an arbitrary JSON object (for all intents and purposes), you could use a JWT as the output of the introspection endpoint as well. -- Justin On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: Not all implementations in the field that do
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Once again, you may want to look at the UMA core I-D to see how it defines an AS/RS interface: http://tools.ietf.org/html/draft-hardjono-oauth-umacore-04 (see particularly Section 3.3) It uses what is by now a very common token introspection pattern to have the RS get the AS's crucial help in validating the token that was presented to it. UMA has a mandatory-to-implement token profile called bearer, which treats the token introspection endpoint as a run-time way to get the content associated with the token blob. Obviously, what's returned from that call is currently UMA-specific (and in fact this class of profiles is called UMA token profiles). Note that the call to the token introspection endpoint must be accompanied by an OAuth token in the header because the endpoint is OAuth-protected. (Yes, it's turtles all the way down...) We haven't yet defined an UMA JWT token profile, but that's the next logical step. This type of introspection functionality could be called a narrow definition of the AS/RS interface requirement. To make it possible to have the AS and RS live in completely separate domains potentially controlled by different parties (a broad definition), a number of other elements would ultimately be required. This is where UMA's entire protection API may be interesting to look at, since it has been demonstrated to apply to typical OAuth use cases (single resource owner) as well as access management use cases (resource owner and requesting party are different). Eve On 19 Apr 2012, at 11:31 AM, Torsten Lodderstedt wrote: Hi Justin, In my opinion, the OpenID Connect introspection/checkid endpoint is a convenience function for clients (not resource servers) unable to decrypt id tokens and validate their signatures. I'm not convinced this function is needed, that's why I proposed to drop it. The AS-PR endpoint servers a different purpose, as it allows to implement handle-based token designs. The AS just creates simple token (e.g. a random number), which is very small and does not need to be encrypted or signed. This might result in simple designs. On the other hand, the PR needs to lookup authz data as part of the request implementation, which might have a negative impact on performance and scalability. That's where self-contained tokens, such as JWT have their merits. I don't think one would combine self-contained tokens with an AS-PR endpoint. Or is this the case in any existing implementations? The point I wanted to make is: no matter how the resource server acquires authz data (as token content/JWT or via request to another AS-PR endpoint), the authz data will be the same. And as part of the JWT standardization, we will identify this data and specify a JSON format to represent it. The same representation could be used at the AS-PR endpoint as well. regards, Torsten. Am 18.04.2012 22:23, schrieb Justin Richer: I think we might be crossing wires about input to the token introspection endpoint vs. output from it. In OpenID Connect, you send a JWT in, and get back a JSON object that represents the Claims bit of the JWT. In our implementation (and I think both Ping and AOL's), you send in an arbitrary token (with no proscribed format) and get back a JSON object with different pieces in it. Ours included a list of scopes and an expiration timestamp, others did different things, like audience and issuer, as part of the return. The point I was trying to make is that the information returned from the AS-PR interface isn't necessarily embedded inside of the token used to call that interface. In OpenID Connect, it is, and the CheckID endpoint just unwraps the JWT for you. In the larger case, what's really going on is that the PR presents a token that it's not sure what it's good for and gets back something that answers that question. Since a JWT Claims section can be an arbitrary JSON object (for all intents and purposes), you could use a JWT as the output of the introspection endpoint as well. -- Justin On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Some of the use cases I have discussed with people also involve returning SAML tokens in the response for dealing with some existing systems. In principal if the RS is authenticated to the AS (perhaps with OAuth) then the correct response format RS can be provided. We need to decide what parts of this get standardized. I am hoping for a interesting discussion on this at IIW that can inform an update to the Ping ID and used as a input for a eventual WG item. John B. Sent from my iPad On 2012-04-18, at 10:23 PM, Justin Richer jric...@mitre.org wrote: I think we might be crossing wires about input to the token introspection endpoint vs. output from it. In OpenID Connect, you send a JWT in, and get back a JSON object that represents the Claims bit of the JWT. In our implementation (and I think both Ping and AOL's), you send in an arbitrary token (with no proscribed format) and get back a JSON object with different pieces in it. Ours included a list of scopes and an expiration timestamp, others did different things, like audience and issuer, as part of the return. The point I was trying to make is that the information returned from the AS-PR interface isn't necessarily embedded inside of the token used to call that interface. In OpenID Connect, it is, and the CheckID endpoint just unwraps the JWT for you. In the larger case, what's really going on is that the PR presents a token that it's not sure what it's good for and gets back something that answers that question. Since a JWT Claims section can be an arbitrary JSON object (for all intents and purposes), you could use a JWT as the output of the introspection endpoint as well. -- Justin On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- 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 smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Hi Justin, In my opinion, the OpenID Connect introspection/checkid endpoint is a convenience function for clients (not resource servers) unable to decrypt id tokens and validate their signatures. I'm not convinced this function is needed, that's why I proposed to drop it. The AS-PR endpoint servers a different purpose, as it allows to implement handle-based token designs. The AS just creates simple token (e.g. a random number), which is very small and does not need to be encrypted or signed. This might result in simple designs. On the other hand, the PR needs to lookup authz data as part of the request implementation, which might have a negative impact on performance and scalability. That's where self-contained tokens, such as JWT have their merits. I don't think one would combine self-contained tokens with an AS-PR endpoint. Or is this the case in any existing implementations? The point I wanted to make is: no matter how the resource server acquires authz data (as token content/JWT or via request to another AS-PR endpoint), the authz data will be the same. And as part of the JWT standardization, we will identify this data and specify a JSON format to represent it. The same representation could be used at the AS-PR endpoint as well. regards, Torsten. Am 18.04.2012 22:23, schrieb Justin Richer: I think we might be crossing wires about input to the token introspection endpoint vs. output from it. In OpenID Connect, you send a JWT in, and get back a JSON object that represents the Claims bit of the JWT. In our implementation (and I think both Ping and AOL's), you send in an arbitrary token (with no proscribed format) and get back a JSON object with different pieces in it. Ours included a list of scopes and an expiration timestamp, others did different things, like audience and issuer, as part of the return. The point I was trying to make is that the information returned from the AS-PR interface isn't necessarily embedded inside of the token used to call that interface. In OpenID Connect, it is, and the CheckID endpoint just unwraps the JWT for you. In the larger case, what's really going on is that the PR presents a token that it's not sure what it's good for and gets back something that answers that question. Since a JWT Claims section can be an arbitrary JSON object (for all intents and purposes), you could use a JWT as the output of the introspection endpoint as well. -- Justin On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- 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] Updated Charter to the IESG (this weekend)
Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- 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] Updated Charter to the IESG (this weekend)
Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- 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] Updated Charter to the IESG (this weekend)
Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- 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] Updated Charter to the IESG (this weekend)
I think we might be crossing wires about input to the token introspection endpoint vs. output from it. In OpenID Connect, you send a JWT in, and get back a JSON object that represents the Claims bit of the JWT. In our implementation (and I think both Ping and AOL's), you send in an arbitrary token (with no proscribed format) and get back a JSON object with different pieces in it. Ours included a list of scopes and an expiration timestamp, others did different things, like audience and issuer, as part of the return. The point I was trying to make is that the information returned from the AS-PR interface isn't necessarily embedded inside of the token used to call that interface. In OpenID Connect, it is, and the CheckID endpoint just unwraps the JWT for you. In the larger case, what's really going on is that the PR presents a token that it's not sure what it's good for and gets back something that answers that question. Since a JWT Claims section can be an arbitrary JSON object (for all intents and purposes), you could use a JWT as the output of the introspection endpoint as well. -- Justin On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- 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] Updated Charter to the IESG (this weekend)
The Ping doc was sent a while back on a different thread about re-charting: http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html I should probably have my people (aka Paul) submit it as an actual I-D? On Sat, Apr 14, 2012 at 8:25 AM, John Bradley ve7...@ve7jtb.com wrote: There is a Ping document. I was talking to openAM/ForgeRock today about a similar endpoint they are working on. Justin can submit his and I will look for the others. John B. Sent from my iPhone On 2012-04-14, at 2:28 PM, Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com wrote: OK, but ___ 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] Updated Charter to the IESG (this weekend)
Justin Richer jric...@mitre.org writes: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. -- Justin -derek -- 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] Updated Charter to the IESG (this weekend)
OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Hi Mike, Hi Justin, it would be important to point to a document or some other write-up so that everyone in the group understands the scope of the work you are proposing to do. Ciao Hannes Sent from my Windows Phone -Original Message- From: ext Justin Richer Sent: 4/13/2012 9:32 PM To: Mike Jones Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? -- Justin On 04/13/2012 01:10 PM, Mike Jones wrote: Yes, there was an explicit decision in that regard. My sense was that the WG did think they're important but they only wanted to take on a manageable number of tasks at once. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Friday, April 13, 2012 10:02 AM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) Did the Introspection Endpoint or Methods for connecting a PR to an AS get dropped? There seemed to be interest in the list in coming up with a generally applicable scheme, or set of schemes, to do this, and there are certainly no shortage of starting points. Both AOL and Ping have their own token introspection drafts that got put to the list, we've developed our own internal approach here, UMA has an alternative approach, and OpenID Connect has invented its own approach for ID Tokens. I just want to make sure that this was an explicit decision of it being out of scope here and not an inadvertent omission. -- Justin On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
There is a Ping document. I was talking to openAM/ForgeRock today about a similar endpoint they are working on. Justin can submit his and I will look for the others. John B. Sent from my iPhone On 2012-04-14, at 2:28 PM, Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com wrote: OK, but smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Did the Introspection Endpoint or Methods for connecting a PR to an AS get dropped? There seemed to be interest in the list in coming up with a generally applicable scheme, or set of schemes, to do this, and there are certainly no shortage of starting points. Both AOL and Ping have their own token introspection drafts that got put to the list, we've developed our own internal approach here, UMA has an alternative approach, and OpenID Connect has invented its own approach for ID Tokens. I just want to make sure that this was an explicit decision of it being out of scope here and not an inadvertent omission. -- Justin On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard [Editor's Note: New work for the group] Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Yes, there was an explicit decision in that regard. My sense was that the WG did think they're important but they only wanted to take on a manageable number of tasks at once. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Friday, April 13, 2012 10:02 AM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) Did the Introspection Endpoint or Methods for connecting a PR to an AS get dropped? There seemed to be interest in the list in coming up with a generally applicable scheme, or set of schemes, to do this, and there are certainly no shortage of starting points. Both AOL and Ping have their own token introspection drafts that got put to the list, we've developed our own internal approach here, UMA has an alternative approach, and OpenID Connect has invented its own approach for ID Tokens. I just want to make sure that this was an explicit decision of it being out of scope here and not an inadvertent omission. -- Justin On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? -- Justin On 04/13/2012 01:10 PM, Mike Jones wrote: Yes, there was an explicit decision in that regard. My sense was that the WG did think they're important but they only wanted to take on a manageable number of tasks at once. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Friday, April 13, 2012 10:02 AM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) Did the Introspection Endpoint or Methods for connecting a PR to an AS get dropped? There seemed to be interest in the list in coming up with a generally applicable scheme, or set of schemes, to do this, and there are certainly no shortage of starting points. Both AOL and Ping have their own token introspection drafts that got put to the list, we've developed our own internal approach here, UMA has an alternative approach, and OpenID Connect has invented its own approach for ID Tokens. I just want to make sure that this was an explicit decision of it being out of scope here and not an inadvertent omission. -- Justin On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] May 2012 Submit 'SAML 2.0 Bearer
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
With the exception of SWD which is still being discussed, this looks good. EH On Apr 12, 2012, at 6:55, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard [Editor's Note: New work for the group] Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration as a
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Hi Hannes, do you mean 'discover relevant OAuth endpoints *for* a resource server'? ie instead of discovering the RS itself? On 4/12/12 6:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard [Editor's Note: New work for the group] Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-simple-web-discovery] Mar.
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Hannes, I took a look (a bit longer than just quick), and what I see completely coincides with my understanding of the result of the discussions. Good job! Igor On 4/12/2012 6:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard [Editor's Note: New work for the group] Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration as a Proposed Standard [Starting point for the work will be
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
I agree that this looks good. My only suggestion is that we move up the proposed submission dates for JWT and JWT Profile from March 2013 to November 2012, since the JOSE specs that JWT is largely based upon are scheduled for submission in July, per http://datatracker.ietf.org/wg/jose/charter/. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor Faynberg Sent: Thursday, April 12, 2012 9:58 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) Hannes, I took a look (a bit longer than just quick), and what I see completely coincides with my understanding of the result of the discussions. Good job! Igor On 4/12/2012 6:55 AM, Hannes Tschofenig wrote: Hey guys based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP
