Re: [OAUTH-WG] OMA Liaison Has Arrived!
Bravo! This has been project-managed masterly. Igor On 8/24/2011 8:32 AM, Barry Leiba wrote: On Mon, Aug 22, 2011 at 1:53 PM, Barry Leiba wrote: I intend to add the following to the response to this item: "The working group understands that client code needs to know whether to use and decode percent-encoding. The issue is being discussed and tracked, and will be resolved before the final version of the bearer document is produced." For confirmation: Murray Kucherawy, our liaison to OMA, delivered our response yesterday (Tuesday, 23 August), and OMA has acknowledged it. They thank us for our prompt response. Barry, as chair - The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled "OAuth discovery and specification availability", dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: • Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. At this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. • Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. • IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. • Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. • For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header Field"), the "scope-v" element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. - ___ 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] OMA Liaison Has Arrived!
On Mon, Aug 22, 2011 at 1:53 PM, Barry Leiba wrote: > I intend to add the following to the response to this item: > "The working group understands that client code needs to know whether > to use and decode percent-encoding. The issue is being discussed and > tracked, and will be resolved before the final version of the bearer > document is produced." For confirmation: Murray Kucherawy, our liaison to OMA, delivered our response yesterday (Tuesday, 23 August), and OMA has acknowledged it. They thank us for our prompt response. Barry, as chair > - > > The IETF OAuth working group thanks OMA ARC SEC for the liaison > statement titled "OAuth discovery and specification availability", > dated 18 July 2011. > > The OMA liaison statement asks the OAuth working group to address five > issues, and our answers are as follows: > > • Availability of the IETF OAuth specifications: especially > [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also > [draft-hammer-oauth-v2-mac-token], > [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. > > Answer: > The IETF cannot guarantee publication dates, but we can give some > best-guess timeframes. At this writing, draft-ietf-oauth-v2 and > draft-ietf-oauth-v2-bearer have completed Working Group last call and > are undergoing their final revisions before being sent to the IESG. > We expect the final versions of those documents to be in the RFC > Editor queue around the end of September, though it could be later if > issues come up in IETF-wide last call or during IESG evaluation. The > draft-hammer-oauth-v2-mac-token document has been replaced by > draft-ietf-oauth-v2-http-mac, which is a working group document. It > is likely to be in the RFC Editor queue by the end of the year. > > The remaining two documents are not working group documents, and the > working group can say nothing about their status. The OAuth working > group intends to revise its charter in the November timeframe, and > it's possible that one or both of those documents could be adopted by > the working group at that time, and we could have further information > about target publication dates then. > > • Availability of the OAuth Parameters Registry > > Answer: > The draft-ietf-oauth-v2 document establishes the OAuth Parameters > Registry (in section 11.2, as of draft version 20). The registry will > be available when the RFC is published, which will be some time after > the document goes into the RFC Editor queue, depending upon the RFC > Editor's load at the time. > > • IETF intent to specify an OAuth Discovery mechanism > > Answer: > There is interest among OAuth working group participants for > specifying such a mechanism, but the work is not in the current > charter. It will likely be considered during the aforementioned > charter update in (approximately) November. > > • Considerations that can help implementors decide about the type of > OAuth access token to deploy. > > Answer: > There is no current work planned, but documents with such > implementation advice might also be considered during the rechartering > discussion. > > • For bearer tokens: clarification whether the non-support of percent > encoding for scope-v element of WWW-Authenticate Response Header Field > grammar is intentional. > > Answer: > In the bearer token document (Section 2.4 of > draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header > Field"), the "scope-v" element is unambiguously defined to allow a > specific set of characters. That set of characters does permit, but > does not mandate, support for percent-encoding of characters. > > - ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
> +1 for Jame's feedback here. We need to solve this. I have opened an issue in the tracker on this: http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 I intend to add the following to the response to this item: "The working group understands that client code needs to know whether to use and decode percent-encoding. The issue is being discussed and tracked, and will be resolved before the final version of the bearer document is produced." Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
+1 for Jame's feedback here. We need to solve this. From: "Manger, James H" To: Barry Leiba ; "oauth@ietf.org" Sent: Thursday, August 18, 2011 4:15 AM Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v >> * For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. > Answer: > In the bearer token document (Section 2.4 of > draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header > Field"), the "scope-v" element is unambiguously defined to allow a > specific set of characters. That set of characters does permit, but > does not mandate, support for percent-encoding of characters. This is a poor answer. A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..." response will either compare it with strings from a OAuth2 JSON-encoded token response, or copy it into a request to an authorization server. It needs to know if it needs to %-decode the value or not before doing these things. Clients cannot be expected to behave differently for different servers in this respect. OAuth2 core (implicitly) allows a scope to use any Unicode char except space (as space is used as a delimiter). Bearer restricts scopes to 93 ASCII chars. OMA are asking if this is intentional. If we really want to restrict scope values it would be better done in OAuth2 core. If we don't want to restrict values then the bearer spec needs to be able to handle any possible scope value by defining an escaping mechanism for scope-v (or by not having a scope parameter). -- James Manger ___ 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] OMA Liaison Has Arrived! scope-v
The text for the answer below came from Mike, as the chairs asked for at the IETF 81 meeting. Mike, do you have a response to James's issue? Can we give a better response here? Should the bearer doc specify %-encoding explicitly? Barry On Thu, Aug 18, 2011 at 7:15 AM, Manger, James H wrote: >>> * For bearer tokens: clarification whether the non-support of percent > encoding for scope-v element of WWW-Authenticate Response Header Field > grammar is intentional. > >> Answer: >> In the bearer token document (Section 2.4 of >> draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header >> Field"), the "scope-v" element is unambiguously defined to allow a >> specific set of characters. That set of characters does permit, but >> does not mandate, support for percent-encoding of characters. > > > This is a poor answer. > A client app receiving a scope value in an "WWW-Authenticate: Bearer > scope=..." response will either compare it with strings from a OAuth2 > JSON-encoded token response, or copy it into a request to an authorization > server. It needs to know if it needs to %-decode the value or not before > doing these things. Clients cannot be expected to behave differently for > different servers in this respect. > > OAuth2 core (implicitly) allows a scope to use any Unicode char except space > (as space is used as a delimiter). > Bearer restricts scopes to 93 ASCII chars. > OMA are asking if this is intentional. > > If we really want to restrict scope values it would be better done in OAuth2 > core. > If we don't want to restrict values then the bearer spec needs to be able to > handle any possible scope value by defining an escaping mechanism for scope-v > (or by not having a scope parameter). > > -- > James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
>> *For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. > Answer: > In the bearer token document (Section 2.4 of > draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header > Field"), the "scope-v" element is unambiguously defined to allow a > specific set of characters. That set of characters does permit, but > does not mandate, support for percent-encoding of characters. This is a poor answer. A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..." response will either compare it with strings from a OAuth2 JSON-encoded token response, or copy it into a request to an authorization server. It needs to know if it needs to %-decode the value or not before doing these things. Clients cannot be expected to behave differently for different servers in this respect. OAuth2 core (implicitly) allows a scope to use any Unicode char except space (as space is used as a delimiter). Bearer restricts scopes to 93 ASCII chars. OMA are asking if this is intentional. If we really want to restrict scope values it would be better done in OAuth2 core. If we don't want to restrict values then the bearer spec needs to be able to handle any possible scope value by defining an escaping mechanism for scope-v (or by not having a scope parameter). -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived!
+1 -Ursprüngliche Nachricht- Von: Barry Leiba [mailto:barryle...@computer.org] Gesendet: Mittwoch, 17. August 2011 22:35 An: oauth@ietf.org Betreff: Re: [OAUTH-WG] OMA Liaison Has Arrived! I'm sorry for the delay in getting this written. Because of the delay, the working group has just a short time to review my proposed response, below. Everyone, please have a look at the answers I propose to send, and post any objections to this thread by the end of the day on Monday, 22 August. Hannes, please also check with the IAB in parallel, and make sure we can send this via Murray as soon as we've resolved any WG objections. Barry, as chair - The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled "OAuth discovery and specification availability", dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: . Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. As this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. . Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. . IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. . Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. . For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header Field"), the "scope-v" element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. - ___ 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] OMA Liaison Has Arrived!
Barry, I personally think that this is both a very thorough and very timely follow-up. (You may consider a minor editorial: "As this writing" in the first answer, should be "As of this writing." Could not catch anything else. The only other suggestion is that maybe the response could omit RFC Queue and other details of the IETF process as those are unfamiliar to OMA. They asked for dates, and the dates are there.) Igor On 8/17/2011 4:34 PM, Barry Leiba wrote: I'm sorry for the delay in getting this written. Because of the delay, the working group has just a short time to review my proposed response, below. Everyone, please have a look at the answers I propose to send, and post any objections to this thread by the end of the day on Monday, 22 August. Hannes, please also check with the IAB in parallel, and make sure we can send this via Murray as soon as we've resolved any WG objections. Barry, as chair - The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled "OAuth discovery and specification availability", dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: • Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. As this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. • Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. • IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. • Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. • For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header Field"), the "scope-v" element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. - ___ 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] OMA Liaison Has Arrived!
I'm sorry for the delay in getting this written. Because of the delay, the working group has just a short time to review my proposed response, below. Everyone, please have a look at the answers I propose to send, and post any objections to this thread by the end of the day on Monday, 22 August. Hannes, please also check with the IAB in parallel, and make sure we can send this via Murray as soon as we've resolved any WG objections. Barry, as chair - The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled "OAuth discovery and specification availability", dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: • Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. As this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. • Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. • IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. • Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. • For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header Field"), the "scope-v" element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. - ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived! [ was Re: Deutsche Telekom launched OAuth 2.0 support]
That's correct. Murray is the liaison and he will provide the response of the liaison to the OMA. I am the liaison shepherd from the Internet Architecture Board. On Jul 29, 2011, at 2:41 AM, SM wrote: > Hi Igor, > At 10:39 PM 7/20/2011, Igor Faynberg wrote: >> the communication can emanate directly from them or IAB can appoint a >> liaison to OMA, who will convey future communications. But this is a >> procedural matter, and I am sure it > > Murray Kucherawy was appointed as liaison to the Open Mobile Alliance in May > 2010 (see > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07457.html ). > > Regards, > -sm > ___ > 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] OMA Liaison Has Arrived! [ was Re: Deutsche Telekom launched OAuth 2.0 support]
Hi Igor, At 10:39 PM 7/20/2011, Igor Faynberg wrote: the communication can emanate directly from them or IAB can appoint a liaison to OMA, who will convey future communications. But this is a procedural matter, and I am sure it Murray Kucherawy was appointed as liaison to the Open Mobile Alliance in May 2010 (see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07457.html ). Regards, -sm ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OMA Liaison Has Arrived! [ was Re: Deutsche Telekom launched OAuth 2.0 support]
Friends, I have intentionally used this thread, on which 1001 messages ago I mentioned the OMA and ITU-T work. Since then I got several private queries, and I am happy to say that the liaison from OMA has arrived (although it has a little glitch, which made me write this otherwise redundant message): https://datatracker.ietf.org/liaison/1069/. The glitch is that the liaison description mistakenly says that 1) the liaison is sent for information and 2) that there is no deadline in response. Section 3 of the document, however, specifies an action for the IETF, and it also gives the deadline of the end of August. This is why I wanted to get the immediate attention. (Another little glitch is that it was supposed to be copied to the OAuth WG, according to the CC list, but this did not happen.) I must say up fornt that I do NOT represent OMA and have no authority whatsoever to speak for it. The reason I am involved in this is because I have been an ardent supporter of OAuth both in my company and in the telecom industry and it has been my vision that the telecom adapt OAuth and combine it with the mobile authentication methods--well I had spoken a lot about that on this list and indicated just this interest in the early profile query. This should make it clear why I am so enthusiastic about OAuth being accepted, and I would like to make sure that we help transition this great product of the OAuth WG. OMA is the center for standardizing mobile applications infrastructure, and its standards are widely used in telecommunictiations industry. Now, OMA has appointed an official Liaison Officer whose role is to speak for OMA officially. In addition, the response--if produced in written form--should by sent to Zhiyuan Hu, who chairs the OMA security group. Handling the liaisons is the IAB job, and the decision on how to process this specific one belongs to OAuth chairmen inasmuch as it has been directed to OAuth. Having dealt with this procedure before, I understand that the communication can emanate directly from them or IAB can appoint a liaison to OMA, who will convey future communications. But this is a procedural matter, and I am sure it will be well sorted out. (In fact, I remember Barry dealing with the OMA liaison in his other group quite expertly.) The technical lead for this work in OMA is my colleague Jerome Marcon (copied here). Jerome knows OAuth as only developers do -- he has implemented it! Jerome has volunteered to answer all questions, and he is both the right and the best person for that. I would like to point out the action of the liaison, which I reproduce here verbatim: "IETF OAuthWG is kindly invited to provide feedback on the points highlighted in this letter: ·Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. ·Availability of the OAuth Parameters Registry ·IETF intent to specify an OAuth Discovery mechanism ·Considerations that can help implementors decide about the type of OAuth access token to deploy. ·For bearer tokens: clarification whether the non-support of percent encoding for scope-velement of WWW-Authenticate Response Header Field grammar is intentional." As these are purely technical questions, some of them relating to our plans, I just thought it might be a good to present them to the list ASAP so that the answers come early. At this point, I am done with what I thought my job was here. Jerome will pick this conversation from now on. Igor On 7/1/2011 5:53 PM, Igor Faynberg wrote: Torsten, With many thanks for the note, I think it would be great if you documented the implementation report in an Informational RFC. In particular, the SIM-based authentication part is of particular interest here--we had this discussion on this list recently-- as it naturally extends the use of the Internet protocols in the telecom environment. I also think that such an implementation report would influence positively the OAuth profiling work that is taking place in ITU-T, OMA and other places. Igor On 7/1/2011 5:19 PM, Torsten Lodderstedt wrote: Hi all, I would like to announce that we recently launched OAuth 2.0 support in our Security Token Service. It will be used in upcoming consumer products (e.g. Smartphone apps). The current implementation supports draft 10 (but is also inline with the latest text on native apps). It has the following additional features: - Issuance of multiple tokens for different services in single authorization process (Bulk User Authorization) - Token revocation (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/) - custom grant types for token exchange and SIM card authentication - Token replacement - Parameter to explicitely request refresh token for "Resource Owner Passwo
