Re: [OAUTH-WG] JWT grant_type and client_id
Yeah, in general the client identification/authentication is independent from the grant being presented. There may be policy (maybe unidentified clients aren't allowed) or other protocol details (like some kind of HoK bound to the client, though that doesn't exist yet) that dictate more requirements on the client identifier. But in the general case they are independent and the client_id is not required. On Mon, Feb 18, 2013 at 5:58 PM, Mike Jones michael.jo...@microsoft.comwrote: The client_id value and the access token value are independent. ** ** -- Mike*** * ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Lewis Adam-CAL022 *Sent:* Monday, February 18, 2013 2:50 PM *To:* oauth@ietf.org WG *Subject:* [OAUTH-WG] JWT grant_type and client_id ** ** ** ** Is there any guidance on the usage of client_id when using the JWT assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention so I assume that it is not required … but it would be necessary if using in conjunction with a HOK profile where the JWT assertion is issued to – and may only be used by – the intended client. Obviously this is straight forward enough, really I’m just looking to be sure that I’m not missing anything. ** ** tx adam ___ 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] Using SAML2 Bearer for the authentication
The scope of assertion based client authentication is only in OAuth and only for the client calling the AS's token endpoint. Defining a general HTTP auth scheme for assertions would have a much broader scope and be much more difficult to standardize. On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin sberyoz...@gmail.comwrote: Hi, Assertions like SAML2 Bearer can be used for authenticating the client. Why a dedicated Authorization scheme can not be introduced, instead of or in addition to client_assertion client_assertion_type parameters ? IMHO, the following Authorization: SAML base64url-encoded assertion grant_type=authorization_code**code=123456 is more in line with OAuth2 recommending not to prefer including client id secret in the body: Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes) - though it talks about a password based scheme... similarly: Authorization: JWT encoded jwt assertion grant_type=authorization_code**code=123456 Just a thought. Cheers, Sergey __**_ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth assertions plan
I do believe some face to face discussion amongst a smallerish group might be valuable on this. I'll be in Orlando and plan on contributing to that as much as I can. Thanks for organizing the lunch discussion Stephen. I do feel that this conversation has strayed a bit and I'd like to clear up one important misconception. The three assertion documents do not define an access token type at all. The questions and concerns around bearer tokens and MAC tokens and other token types may well be very legitimate but are completely orthogonal to the scope and intent of the assertion documents. The assertions drafts define how to trade an assertion for a an access token at the token endpoint via the extension grant type mechanism provided by RFC 6749. The assertions drafts also define an alternative means of client authentication but its scope is very limited and only applies to a client authenticating to the AS's token endpoint. I believe the documents are pretty clear on what they seek to accomplish (and what they do not) but this is definitely not the first time this has come up and that likely points to the need for some more clarification in docs themselves. It seems to me that much of the recent discussion here is largely unrelated to that actual intent and scope of the documents in question. It may well be valuable discussion but, even if we can find some common ground on it, these assertion drafts probably aren't the right place to address these issues. On Mon, Feb 18, 2013 at 12:09 PM, Barry Leiba barryle...@computer.orgwrote: Dynamically declaring, in what sense? Where are those mechanisms documented? ** ** Many of them are documented in draft-ietf-oauth-dyn-reg. ** ** One profile (an outer doll J) that enables fully interoperable implementations is documented in draft-hardjono-oauth-umacore. ... Another related profile that enables fully interoperable implementations is documented in http://openid.net/specs/openid-connect-messages-1_0.html. It's possible, then, that this isn't an issue of major changes needed in this document, but one of document ordering. It's possible (I'm still not sure, but maybe) that if some of these other documents came out before or at the same time as this one, they would all fit together and all would be clear. So maybe that's one way through this. In the end, all I'm saying is that if I hear that everyone is using oauth to peel bananas, and I want put my banana-peeling application on the market by adding oauth to it, I need to be able to read a set of specs that say how to do that, and that's all. And if I do that, my application will work when it's slotted into any oauth-based banana-peeling system. Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] comments on draft-ietf-oauth-saml2-bearer-15
Thanks for the feedback Prateek. I've tried to address some of you comments and questions inline below. On Wed, Feb 13, 2013 at 3:53 PM, Prateek Mishra prateek.mis...@oracle.comwrote: It would be helpful if the draft identified the various cases that are intended to be supported. For example, in draft-ietf-oauth-assertions-**10, there is a helpful distinction made between Client acting on behalf of a user vs. Client Action on behalf of an anonymous user (vs. even more advanced use-cases). Otherwise, folks have a hard time figuring out the pieces they need to implement and the required behavior. The guidance in §6 of draft-ietf-oauth-assertions-10 provides some particular details of the more general general cases and they apply here as well as the JWT draft. I'd like to avoid repeating the text and bloating the documents. It feels like Section 3 speaks to all of these cases simultaneously. I think this is confusing and our developers have raised some questions about it. It's not really intended to speak to the cases so much as provide the required processing rules to validate the assertion in a reasonably secure way. There is some simultaneous treatment of the client authentication case and the authorization grant case because they have much more in common than they have that's different. I can make a pass at better pointing out where the differences are. BTW, it would also help if the rules in Section 3 were numbered. I'll see what I can do. I assume it's possible with the xml2rfc markup but have never done it. 1) For the case where we have Client acting on behalf of user - this case seems to be where we have something like a SAML SSO assertion - complete with Subject identifying the authorized accessor or delegate. The Client offers this bearer instrument as an access grant and the Authorization server understands that its acting on behalf a user. a) As the SAML assertion is a bearer instrument and can be stolen, the authorization server should insist on client credentials being present. In other words, the client should be confidential. What is the value in permitting a public client to participate in this exchange? Very similar to SAML Web SSO where the client (HTTP user agent browser in that case) is unidentified and the bearer assertion is the sole token provided to identify/authenticate the subject and gain access. In some cases there is a quite a bit of value in not having to provision or manage the clients. b) Further, as part of its processing rules, once the client has been authenticated the authorization server should determine whether the particular client has the right to present the SAML bearer assertion. An AS is free to deploy that kind of policy as needed for the deployment or product. But the spec intentionally does not dictate any such policy. And intentionally allows for unidentified clients. c) What is the value of including an AuthNStatement? Specifically, what does the Authorization server understand by its presence or absence? What is the guidance to deployers? Should they require end-user authentication to have taken place? It's intended to convey whether or not the issuer actually authenticated the subject or not. It's a distinction that, based on some conversations I'd had, seemed like it might be useful for some. But much existing SAML software doesn't work that way currently, which is why there's not a MUST there. I'm trying to accommodate existing practice, within reason, while also provide potentially useful functionality. 2) Bullet 5 (counting from the bottom of Section 3) references a more advanced use case based on a SAML delegation model. Is this the ONLY case where AuthNStatement's are allowed to be omitted? If so, that should be stated clearly. I've got a SHOULD NOT there. I don't think a MUST is reasonable based on what I've seen actual deployments do. Please suggest some text, if you think it can be improved. I think this bullet refers to an advanced use-case and should be moved to an independent section. I think it's pretty common actually. I think by the presenter act autonomously on behalf of the subject you mean something like Client acts on Behalf of Anonymous Users. as identified in draft-ietf-oauth-assertions-**10. No. I mean that the presenter (client) is acting on behalf of the user. And the user probably isn't present for the transactions. Autonomous is a word that kind of got inherited from the very early OAuth 2.0 drafts ( http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-1.4.4) and maybe causes more trouble than it's worth here? I also found the sentence The presented SHOULD be identified in the NameID or similar element,.. problematic. Its pretty open ended and it seems to me it will be difficult to have an interoperable implementation based on this text. I agree that it's confusing and I believe it's partly because there's a mistake in that text. It
Re: [OAUTH-WG] Registration: JSON Encoded Input
+1 to what Pat and Justin said.
On Tue, Feb 12, 2013 at 12:59 PM, Justin Richer jric...@mitre.org wrote:
If that's the question, then my proposal is the Content-type is
application/json and the HTTP Entity Body is the JSON document. No form
posts or parameter names to be had here.
-- Justin
On 02/12/2013 02:58 PM, John Bradley wrote:
Some people apparently encode the JSON as the key in a form POST, some
people do a form POST with a special key and the JSON as the value.
There appear to be a number of theories in the wild. I am not an
expert I just looked up code examples from several sources stack overflow
and the like.
We probably need to get input from developers who have experience
working with different frameworks. I think the differences have to do
with decoding it at the receiver.
We originally had registration posting JSON but we changed form encoding
as that worked in all environments. We just need to be sure we are not
creating problems for people with the change back.
John B.
On 2013-02-12, at 4:48 PM, Tim Bray twb...@google.com wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley ve7...@ve7jtb.com wrote:
Nat and I hashed out the pro's and cons of JSON requests.
If we POST or PUT a JSON object we need to be specific as there rare
several ways to do it that may work better or worse depending on the
receiver.
This needs to be looked over and one picked.
Hm? Not following on “several ways”, I’d have thought that POSTing JSON
is just POSTing JSON, must be missing something. -T
In the other thread about the server returning the update URI and being
able to encode the client in that if it needs to takes care of Servers that
need that info in query parameters or the path to do the routing.
The use of structure can be used to enhance readability and parsing of
the input, and output.
However we need to temper our urge to apply structure to everything.
IT needs to be applied carefully otherwise we start looking like
crazies.
If we do it cautiously I am in favour of JSON as input.
John B.
On 2013-02-12, at 4:32 PM, Justin Richer jric...@mitre.org wrote:
Thanks for forwarding that, Mike. I'll paste in my response to Nat's
concern here as well:
It's an increasingly well known pattern that has reasonable support on
the server side. For PHP, I was able to find the above example via the top
hit on Stack Overflow. In Ruby, it's a matter of something like:
JSON.parse(request.body.read)
depending on the web app framework. On Java/Spring, it's a matter of
injecting the entity body as a string and handing it to a parser (Gson in
this case):
public String doApi(@RequestBody String jsonString) { JsonObject json =
new JsonParser().parse(jsonString).getAsJsonObject();
It's a similar read/parse setup in Node.js as well.
It's true that in all of these cases you don't get to make use of the
routing or data binding facilities (though in Spring you can do that for
simpler domain objects using a ModelBinding), so you don't get niceities
like the $_POST array in PHP handed to you. This is why I don't think it's
a good idea at all to switch functionality based on the contents of the
JSON object. It should be a domain object only, which is what it would be
in this case.
I think that the positives of using JSON from the client's perspective
and the overall protocol design far outweigh the slightly increased
implementation cost at the server.
-- Justin
On 02/12/2013 02:11 PM, Mike Jones wrote:
FYI, this issue is also being discussed as an OpenID Connect issue at
https://bitbucket.org/openid/connect/issue/747. I think that Nat's
recent comment there bears repeating on this list:
Nat Sakimura:
Not so sure. For example, PHP cannot get the JSON object form
application/json POST in $_POST.
It is OK to have a parameter like request that holds JSON. Then, you
can get to it from $_POST['request']. However, if you POST the JSON as the
POST body, then you would have to call a low level function in the form of:
```
#!php
$file = file_get_contents('php://input'); $x = json_decode($file); ```
Not that it is harder, but it is much less known. Many PHP programmers
will certainly goes ???.
We need to check what would be the cases for other scripting languages
before making the final decision.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org
[mailto:oauth-boun...@ietf.orgoauth-boun...@ietf.org]
On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input
Draft -05 of OAuth Dynamic Client Registration [1] switched from a
form-encoded input that had been used by drafts -01 through -04 to a JSON
encoded input that was used originally in -00. Note that all versions keep
JSON-encoded output from all
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
I apologize for not participating in much of the discussion around this - I've been otherwise occupied this week with a myriad of other priorities at work. I would, however, like to voice my support in favor of the version of the text that Mike proposed. On Fri, Jan 18, 2013 at 3:59 PM, Mike Jones michael.jo...@microsoft.comwrote: To make the proposed changes concrete, I've made them in a proposed draft 10 (attached). This contains no normative changes from draft 9. People should look at Section 1.1 (Interoperability Considerations) and review the new text there. The only other change was renaming Principal to Subject to align terminology with the SAML and JWT specs, as discussed on the list. I will wait for OK from one of the chairs or Stephen before checking this in. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, January 18, 2013 2:31 PM To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today I can't agree with proceeding with Hannes' rewrite of the interoperability text, as editorially, it reads like it is apologizing for a defect in the specification, whereas it is an intentional feature of the specification that the syntax and verification rules of some fields is intentionally left open for profiles to specify (even while the semantics of them is defined by the Assertions spec). I propose that instead, we go with the revised version at the end of this message, which I believe incorporates Hannes' ideas while keeping the editorial tone positive. Second, I believe that we should proceed with the non-normative terminology change of Principal to Subject, which was proposed in http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and supported by Justin and Torsten, with no one opposed. This should go into the version being discussed on the telechat (as well as the interoperability text). Finally, I believe that it would be beneficial to all to have the Assertions and SAML Profile specs be discussed on the same telechat, as both are useful for understanding the other. Frankly, I think they should go to the IETF Editor together as related specifications, with the goal being consecutively numbered RFCs referencing one another. Is there any reason we can't schedule both for the February 7th telechat? (I don't actually understand how they failed to proceed in lock-step in the first place. Chairs - any insights?) Interoperability Considerations This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework in which the data formats used for representing many values are not defined, on its own, this specification is not sufficient to produce interoperable implementations. Two other specifications that profile this framework for specific assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web Tokens (JWTs). These two instantiations of this framework specify additional details about the assertion encoding and processing rules for using those kinds of assertions with OAuth 2.0. However, even when profiled for specific assertion types, additional profiling for specific use cases will be required to achieve full interoperability. Deployments for particular trust frameworks, circles of trust, or other uses cases will need to agree among the participants on the kinds of values to be used for some abstract fields defined by this specification. For example the values of Issuer, Subject, and Audience fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, IP addresses, or other values, depending upon the requirements of the particular use case. The verification rules for some values will also be use case specific. This framework was designed with the clear expectation that additional specifications will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability for particular use cases. Thanks all, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Friday, January 18, 2013 9:47 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today Hiya, So I'll take the lack of further discussion about this an meaning that the wg want this to shoot ahead. I'll put this in as an RFC editor note for the draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi all, As you have seen on the list (see
[OAUTH-WG] Missed comments on the assertion framework
There were some comments on the document made by Shawn Emery as part of a security directorate's review http://www.ietf.org/mail-archive/web/secdir/current/msg03679.html that seem to have gotten lost in the shuffle. His editorial comments are spot on and I believe the changes he suggests should all be made. I'm not sure if a new draft or a RFC editor's note is more appropriate at this stage? The question about providing more guidance on the Assertion ID is a little less straightforward. The JWT and SAML instances of the framework both inherit some guidance from their respective token format definitions - http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-4.1.7and §1.3.4 ID and ID Reference Values of saml-core-2.0-os. Perhaps that is sufficient. If we were to add something to draft-ietf-oauth-assertions, I'd probably look to borrow some text from one or both of those locations. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
That text around audience in the framework spec changed from a SHOULD to a MAY in -09 so that it would be more consistent with the the SAML and JWT versions, which were already using a MAY in that context. Your concern is valid Hannes and your point is taken. But reality is rather messy and I don't believe it can addressed as easily as you suggest. In SAML, for example, an entity identifier is often used as a value for the audience (per spec and in practice). But an AS may not necessarily identify itself with a full blown SAML entity, in which case the token endpoint URI is more appropriate. The whole issue is also somewhat complicated in SAML too by it having both audience and recipient that are similar but not the same. I've tried to account for all of this in the SAML doc but it's admittedly somewhat awkward and complex and not as simple as saying the value has to be X and must be validated in exactly such a way. JWT doesn't have the same history and baggage of SAML but is subject to many of the same real world deployment variations. I'm definitely open to improvements with respect to the handling of audience values but I believe anything that is done needs to reflect the realities of current implementations and deployments as well as related specifications., On Fri, Jan 11, 2013 at 8:55 AM, John Bradley ve7...@ve7jtb.com wrote: Yes in assertions it needs to be general. It is the JWT and SAML profiles that need to nail down what the format of the audience is.They should probably both be the URI of the token endpoint. In both SAML and JWT there can be multiple audiences for the token. John On 2013-01-11, at 11:37 AM, Richer, Justin P. jric...@mitre.org wrote: It's my understanding that the general assertions claim is more of a conceptual mapping than it is a concrete encoding, so anything more specific here would be out of place. I would like the authors to either confirm or correct my assumptions, though. -- Justin On Jan 11, 2013, at 6:30 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like.
[OAUTH-WG] Open Issue in draft-ietf-oauth-json-web-token-06
I noticed the open issue quoted below while perusing the diffs of some new I-Ds today and it reminded me that I'd been meaning to comment on that very issue. Should all claims continue to be required to be understood by implementations using them when used in a security-related context or should a means of declaring that specific claims may be safely ignored if not understood should be defined? This is related to the similar JOSE issue about whether all header fields must continue to be understood. I've been reluctant to weigh in on the similar JOSE discussion for lack of confidence about the right answer but I do have a lot of experience working with identity and security type tokens that may be relevant to the issue in the JWT context. In my experience many consumers of such tokens will process the special attributes/claims that it knows about (i.e. aud, iss, exp, etc.) and pass the remaining values to the application layer as (not necessarily expected but potently useful) additional claims about the subject. In fact, I recently wrote a JWT/JWS based OAuth access token implementation that does exactly that (which a colleague of mine successfully tested with a MS JWT implementation although I don't know what claims he used). Maybe that's not the best approach but I believe it's fairly common and, as such, that must understand requirement in JWT is likely to be ignored by many, which can result in a neglected spec requirement and/or potential interoperability issues. My 2 cents, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
I believe John meant to refer to Google's adding of the *cid* claim rather than the *prn* claim. On Thu, Dec 27, 2012 at 5:53 PM, John Bradley ve7...@ve7jtb.com wrote: The discussion on the Connect call was that audience could be a literal or an array. example aud:[http://audiance1.com,http://audiance2.com;] In some cases the token may want to have more than a single audience. (anthropomorphic license) in the simple case it would still be aud:http://audiance1.com; While dynamic typing of variables is not my favourite thing in principal, I am assured that this is common JSON syntax that people can deal with. The idea is to standardize this rather than everyone coming up with their own way around the restriction as google did by adding the prn claim. At least this way if you only trust tokens with yourself as the audience you have a easy way to check. John B. On 2012-12-27, at 7:57 PM, Anthony Nadalin tony...@microsoft.com wrote: What do you mean by multi-valued and what are the semantics of multi-vale ? *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley *Sent:* Thursday, December 27, 2012 5:32 AM *To:* Mike Jones *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI? ** ** Agreed. ** ** We need to clarify that the value of the audience claim can be multi valued as well. ** ** John B. ** ** On 2012-12-26, at 10:43 PM, Mike Jones michael.jo...@microsoft.com wrote: http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 currently says: Audience A URI that identifies the party intended to process the assertion. The audience SHOULD be the URL of the Token Endpoint as defined in Section 3.2 http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-3.2 of OAuth 2.0 [RFC6749 http://tools.ietf.org/html/rfc6749]. I think that “URI” should be changed to “value”, since audience values in general need not be URIs. In particular, in some contexts OAuth client_id values are used as audience values, and they need not be URIs. Also, SAML allows multiple audiences (and indeed, the OAuth SAML profile is written in terms of “an audience value” – not “the audience value”), and so the generic Assertions spec should do likewise. Thus, I would propose changing the text above to the following: Audience A value that identifies the parties intended to process the assertion. An audience value SHOULD be the URL of the Token Endpoint as defined in Section 3.2 http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-3.2 of OAuth 2.0 [RFC6749 http://tools.ietf.org/html/rfc6749]. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
I agree that “URI” should be changed to “value” for audience in the Assertions Spec (draft-ietf-oauth-assertions) as well as the JWT incarnation of it (draft-ietf-oauth-jwt-bearer). The SAML incarnation (draft-ietf-oauth-saml2-bearer) should probably keep URI because that's how the core SAML specification (saml-core-2.0-os) defines audience. On Wed, Dec 26, 2012 at 6:43 PM, Mike Jones michael.jo...@microsoft.comwrote: http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1currently says: ** ** Audience A URI that identifies the party intended to process the assertion. The audience SHOULD be the URL of the Token Endpoint as defined in Section 3.2 http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-3.2 of OAuth 2.0 [RFC6749 http://tools.ietf.org/html/rfc6749]. ** ** I think that “URI” should be changed to “value”, since audience values in general need not be URIs. In particular, in some contexts OAuth client_id values are used as audience values, and they need not be URIs. Also, SAML allows multiple audiences (and indeed, the OAuth SAML profile is written in terms of “an audience value” – not “the audience value”), and so the generic Assertions spec should do likewise. ** ** Thus, I would propose changing the text above to the following: ** ** Audience A value that identifies the parties intended to process the assertion. An audience value SHOULD be the URL of the Token Endpoint as defined in Section 3.2 http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-3.2 of OAuth 2.0 [RFC6749 http://tools.ietf.org/html/rfc6749]. ** ** -- Mike ** ** ___ 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] Summary - Assertion Framework - Why does issuer have to be either the client or a third party token service?
They are just some examples and shouldn't limit who or what can be the issuer. Maybe just removing that whole sentence that says, The issuer may be either an OAuth client (when assertions are self-issued) or a third party token service.' would be better, if it's causing confusion? On Mon, Dec 17, 2012 at 5:29 PM, zhou.suj...@zte.com.cn wrote: oauth-boun...@ietf.org 写于 2012-12-17 23:21:36: Hi all, I read through the mailing list discussion raised by Nat in this mail to the list on the 3rd of December, see http://www.ietf. org/mail-archive/web/oauth/current/msg10203.html There were two types of issues: 1) The current text about the issuer (in Section 5.1 of draft-ietf- oauth-assertions-08.txt says that the assertion can either be created by the client (in which case it is self-signed) or it can be created by some other entity. There was, however, the perception that the current text, in the way it is worded, creates the impression that third party token services excludes entities like the resource owner. 2) Some folks had the idea that the resource owner could create the assertion and they had a specific use case in mind. While this is not a currently deployed scenario (using OAuth technology) there seem to be some other deployment (the Austrian eID card deployment was mentioned by Nat) that could be re-build with this support in mind. It seemed that just mentioning that the resource owner could create the assertion wouldn't be enough to understand the scenario. A more detailed writeup of the envisioned scenario would be needed but has not been provided to the mailing list. To me it seems that the best approach would be to do the following: a) to update the text in Section 5.1 as suggested by Nat in his mail http://www.ietf.org/mail-archive/web/oauth/current/msg10222.html Nat's suggestion Example of issuers include an OAuth client, resource owner, an independent third party. there is still an issue, indenpendent from who? If AS be an assertion issuer, could AS be called indenpendent? This by itself would not lead to any normative text change but may make it clear what the intention was. b) to encourage those who care about the use case where the resource owner creates the assertion to compile a document and to submit it to the group. This would allow us to evaluate whether all the required functionality is indeed available. Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Additional informative references for Assertions draft
+1 for the references On Wed, Dec 19, 2012 at 3:06 PM, Mike Jones michael.jo...@microsoft.com wrote: BTW, the SAML purists would probably point out that I should have written “SAML 2.0 assertions” – not “SAML 2.0 tokens” below. J From: Justin Richer [mailto:jric...@mitre.org] Sent: Wednesday, December 19, 2012 1:42 PM To: Mike Jones Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Additional informative references for Assertions draft +1, cross references are a good thing when documents are split up. On 12/19/2012 04:33 PM, Mike Jones wrote: I’d suggest adding informative references to the OAuth SAML and JWT Profile documents in the Assertions draft. After this sentence of the Introduction: In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. I’d add the following: For instance, the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 [draft-ietf-oauth-saml2-bearer] defines a concrete instantiation for SAML 2.0 tokens and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 [draft-ietf-oauth-jwt-bearer] defines a concrete instantiation for JWT tokens. Doing that will help readers find the concrete instances from the abstract specification. Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] JWT audience claim
WG folks, I'm wondering if the current definition of the aud (audience) claim in JWT [1], which limits the value of the claim to a case sensitive string containing a StringOrURI value, might not be flexible enough? In thinking about or discussing various potential applications of JWT, the possibility of having a token intended for consumption by more than one entity has come up frequently. One such example would be an AS that is using JWTs as structured access tokens intended for use at multiple RSs and wants to audience restrict those access tokens. Doing that with the current JWT and aud claim could be rather awkward in that a single aud value would need to somehow represent multiple entities, which seems likely to be done in very application specific ways that would not result in much interoperability. Scope is potentially applicable in this case but isn't standardized at that level and wouldn't be useful outside of OAuth specific applications. At a high level, I'm proposing that we consider changing the definition of aud to allow for an array of StringOrURI values. And change the processing requirement such that the thing consuming the claim must identify itself with [at least] one of the values of the aud claim array. That would allow a JWT AT that's intended for consumption by RS 1, 2 and 3 to be audience restricted like this, aud: [RS1, RS2, RS3] and an individual RS just needs to find itself in one of the values of the claim. Such a change would add some complexity but I'm beginning to think that it's a good trade off for the added flexibility it brings. The validation would be basically the same but just over a list of values rather than against a single one. We would have to decide whether the case of a single audience could still be represented as it is now or if everything would always have to be an array (i.e. aud: RS vs. aud: [RS] ). The former introduces slightly more complexity to validation but is a nice optimization for the common case and would preserve compatibility with existing implementations. Thoughts, comments, questions, or angry diatribes? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT audience claim
Inline... On Tue, Dec 18, 2012 at 3:14 PM, John Bradley ve7...@ve7jtb.com wrote: We probably also need to consider this in light of people like Google already adding new JWT claims to specify a secondary audience, though there 'cid' Client ID claim is more about who requested the token. There is a lot of similarity. When I first heard about the cid claim, I wondered if they might have used multiple aud values to accomplish the same thing, if that been readily available in the spec. There are some subtle differences between the two and I don't fully understand the reasons for going with that secondary claim name. I am not keen on claims that are sometimes a literal and sometimes an array, though it works in JSON it can be confusing. Are you proposing that aud us always an array with one or more values, or that it is a literal if it is one value and array if more than one? I could go either way. But I'd lean towards the latter given all the considerations. The other way to deal with it is having a abstract audience that all the recipients recognize. Though that has its own issues. Indeed. And is complicated in applications or specifications that require audience to be a very specific value (OpenID Connect, for example, dictates that the aud of the id token MUST be the OAuth 2.0 client_id of the Client.). Having one way to do it would be better, I just don't have a good feeling that it is worth complicating the simple case where there is only one audience. Fair enough. I might be convinced of the utility for aud to be an array if you need mopre than one value and leave the single case as a literal. I think that's where it'll end up, if there's a (rough) consensus to make a change. John B. On 2012-12-18, at 6:41 PM, Brian Campbell bcampb...@pingidentity.com wrote: WG folks, I'm wondering if the current definition of the aud (audience) claim in JWT [1], which limits the value of the claim to a case sensitive string containing a StringOrURI value, might not be flexible enough? In thinking about or discussing various potential applications of JWT, the possibility of having a token intended for consumption by more than one entity has come up frequently. One such example would be an AS that is using JWTs as structured access tokens intended for use at multiple RSs and wants to audience restrict those access tokens. Doing that with the current JWT and aud claim could be rather awkward in that a single aud value would need to somehow represent multiple entities, which seems likely to be done in very application specific ways that would not result in much interoperability. Scope is potentially applicable in this case but isn't standardized at that level and wouldn't be useful outside of OAuth specific applications. At a high level, I'm proposing that we consider changing the definition of aud to allow for an array of StringOrURI values. And change the processing requirement such that the thing consuming the claim must identify itself with [at least] one of the values of the aud claim array. That would allow a JWT AT that's intended for consumption by RS 1, 2 and 3 to be audience restricted like this, aud: [RS1, RS2, RS3] and an individual RS just needs to find itself in one of the values of the claim. Such a change would add some complexity but I'm beginning to think that it's a good trade off for the added flexibility it brings. The validation would be basically the same but just over a list of values rather than against a single one. We would have to decide whether the case of a single audience could still be represented as it is now or if everything would always have to be an array (i.e. aud: RS vs. aud: [RS] ). The former introduces slightly more complexity to validation but is a nice optimization for the common case and would preserve compatibility with existing implementations. Thoughts, comments, questions, or angry diatribes? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5 ___ 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] Using structured access_token as grant type in assertion flow
Maybe I'm missing the bigger picture but, if your going back to the same AS like the diagram shows, why not just request the xyz scope in the initial request and cut out the middle steps? More generally I can say I've thought about these kinds of token exchange cases and they should be possible in theory. In practice I expect getting everything to work and validate correctly with respect to scopes and audience values might be a little tricky. On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 adam.le...@motorolasolutions.com wrote: Hi, I continue to have an interest in the OAuth assertion profiles for my use cases. I'm wondering if the idea of performing a first OAuth dance which returns to the client a structured JWT access token (with scope=AS for example) could then be used as the JWT in an assertion grant type? So something like this (I show the RO credential flow since it is the simplest to draw, but same idea for the code flow): Client AS | | || (authorization request scope=AS, grant_type=RO password credentials) | | || (token response with access_token scoped to AS) | | || (authorization request, scope=xyz, grant_type=JWT assertion as obtained from previous step) | | || (token response with access token scoped to xyz) I suppose there is nothing in theory which should prevent this, but I am wondering if anybody else has thought of such a usage. ___ 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] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Those are common steps for obtaining an assertion from an STS but the only possibly way. The assertion framework document doesn't or shouldn't impose any requirements or restrictions on how the client obtains an assertion. Two common ways are discussed as examples but they are by no means indeed to constrain clients from doing something else. On Mon, Dec 10, 2012 at 6:41 PM, zhou.suj...@zte.com.cn wrote: In section 3 The token service is the assertion issuer; its role is to fulfill requests from clients, which present various credentials, and mint assertions as requested, fill them with appropriate information, and sign them. As I understand, an assertion generated by a STS, is done flollowing thess steps: 1. Client presents credential and requests an assertion 2. STS generates assertion and sends to Client Correct? It is an interactive process, but there are cases that credential from client is not necessary, e.g. my RO issuer use case: 1. RO generate a delegation statement specifying client-name has the right to do something, signs it, sends to client. No client credential is needed, and even request from client is not needed. Any comments? ZhouSuJing00132831/user/zte_ltd 写于 2012-12-07 08:17:00: Brian Campbell bcampb...@pingidentity.com 写于 2012-12-07 07:03:38: A question for the chairs or others more versed in the workings of the IETF - is this document even in a place where changes can be made? The Shepherd Write-Up for the document was recently sent to the IESG Secretary and I'm honestly not sure what the protocol is for making changes at this point. Or we can start a new draft extending and clarifying the assertion document, more use cases could be implemented by assertion may be included, and other things... On Thu, Dec 6, 2012 at 12:50 AM, Nat Sakimura sakim...@gmail.com wrote: Here, I think it is better to differentiate the entity and function/role. Authorization Server in OAuth is kind of entity. Its function actually is split into two, or in most cases three. 1. Authentication Endpoint 2. Authorization Endpoint 3. Token Endpoint Now, Assertion Verifier is a function/role. It is performed by 3. Token Endpoint. It check the validity, and issues access tokens (which in turn can be another assertion by the way.) Authorization Endpoint is another function. It can be located anywhere. In your case, it is located in what you call as Resource Owner (Browser plug-in?) In my Self-Issued IdP case, it is issued by the App in the phone which is called by the custom schema. This is the reason why I constantly grumble that it is better to speak in terms of functions rather than entities. Functions may reside in any entity, and if we talk only in terms of the entities, the combination will explode. Nat On Thu, Dec 6, 2012 at 9:46 AM, zhou.suj...@zte.com.cn wrote: As I understand, RO=issuer does not mean RO=AS. RO as an issuer generates assertion (if the assertion is similar to delegation statement in my use cases), AS as an assertion verifier receives the assertion and check its validity. oauth-boun...@ietf.org 写于 2012-12-06 01:35:10: Just checking that I understand: If the RO == the issuer, then the RO == the AS, right? Just as in Nat's example, the user (or at least the device presenting a user agent to them) == the IdP? Colocating the RO and AS functions shouldn't be precluded, but I would be awfully confused if there were an RO/issuer in the picture and *also* an AS that *doesn't* issue assertions. Eve On 5 Dec 2012, at 9:13 AM, Nat Sakimura sakim...@gmail.com wrote: It is not OAuth, but Austrian eID system is an example of RO as an assertion issuer pattern. They have their own SAML IdP on their PC (at least a few years ago) and combined with the qualified certs in the user's smart card and another file, creates a SAML assertion with sectoral identifier and supply it to other systems. Nat On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell bcampb...@pingidentity.com wrote: I say that it's only theoretical because I don't believe there are any actual deployments supporting, or planning on supporting, RO as an assertion issuer. On Tue, Dec 4, 2012 at 5:39 PM, zhou.suj...@zte.com.cn wrote: Why RO as an issuer is only theoretical today? Brian Campbell bcampb...@pingidentity.com 2012-12-04 23:41 收件人 Nat Sakimura sakim...@gmail.com 抄送 zhou.suj...@zte.com.cn, oauth@ietf.org oauth@ietf.org 主题 Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? The intent was definitely not to constrain who/what could be the issuer. But also try to provide some
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
I say that it's only theoretical because I don't believe there are any actual deployments supporting, or planning on supporting, RO as an assertion issuer. On Tue, Dec 4, 2012 at 5:39 PM, zhou.suj...@zte.com.cn wrote: Why RO as an issuer is only theoretical today? *Brian Campbell bcampb...@pingidentity.com* 2012-12-04 23:41 收件人 Nat Sakimura sakim...@gmail.com 抄送 zhou.suj...@zte.com.cn, oauth@ietf.org oauth@ietf.org 主题 Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? The intent was definitely not to constrain who/what could be the issuer. But also try to provide some guidance around the common cases that are actually being deployed now, which are the client self-issued and STS variants. Resource owner as an issuer is an interesting case but seems mostly theoretical at this point. I feel like mentioning the resource owner there in §5.1 would cause more confusion than anything else. I'd prefer to just strike the whole sentence in question and maybe add some additional text to §3 that clarifies that the issuer can really be any entity, if folks think a change is needed here? On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura *sakim...@gmail.com*sakim...@gmail.com wrote: Actually, The issuer may be either an OAuth client (when assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. is not really clean. OAuth client is just another example of an issuer. So, perhaps the sentence could be: Example of issuers include an OAuth client, resource owner, an independent third party. So, the clause becomes: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. Example of issuers include an OAuth client, resource owner, an independent third party. Nat Nat On Tue, Dec 4, 2012 at 11:40 AM, *zhou.suj...@zte.com.cn*zhou.suj...@zte.com.cn wrote: Chuck Mortimore *cmortim...@salesforce.com* cmortim...@salesforce.com 写于 2012-12-04 10:26:50: Please feel free to suggest better language. Issuer simply allows the token service to know who created the assertion, so it can look them up and see if they're trusted. Effectively the same as an Issuer in SAML. a conflict : The token service is the assertion issuer in assertion document. while you said token service know who created the assertion I wonder if the following text is acceptable: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. The issuer may be either an OAuth client (when assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. 6.3. Client Acting on Behalf of a User The Issuer of the assertion MUST identify the entity that issued the assertion as recognized by the Authorization Server. If the assertion is self-issued, the Issuer SHOULD be the client_id. If the assertion was issued by a Security Token Service (STS), the Issuer SHOULD identify the STS as recognized by the Authorization Server.If the assertion was issued by the resource owner, the Issuer SHOULD identify the resource owner as recognized by the Authorization Server. -cmort On Dec 3, 2012, at 6:23 PM, *zhou.suj...@zte.com.cn*zhou.suj...@zte.com.cn wrote: Obviously, it is not so clear from the language there. Chuck Mortimore *cmortim...@salesforce.com* cmortim...@salesforce.com 写于 2012-12-04 10:17:12: There's no reason why it can't be resource owner today. On Dec 3, 2012, at 6:06 PM, *zhou.suj...@zte.com.cn*zhou.suj...@zte.com.cn *zhou.suj...@zte.com.cn* zhou.suj...@zte.com.cn wrote: +1. And why it was not looked at that time? *oauth-boun...@ietf.org* oauth-boun...@ietf.org 写于 2012-12-04 01:30:55: Actually, I think it is a good time to start looking at the resourse owner issuing assertions@ (Interestingly enough, Hui-Lan had brought this up a couple of years ago.) Igor On 12/3/2012 3:58 AM, Nat Sakimura wrote: I suppose, yes. I was reading it like that all the time. Whether it is or not, if it is still ok, it might be better to clarify it. Word like third party tends to be a bit of problem without clearlydefining. I had similar experience in other fora. Nat Sent from iPad 2012/12/03 0:52、*zhou.suj...@zte.com.cn* zhou.suj...@zte.com.cn *zhou.suj...@zte.com.cn* zhou.suj...@zte.com.cn の メッセ�`ジ: could be Resource owner? Tschofenig, Hannes (NSN - FI/Espoo) *hannes.tschofe...@nsn.com*hannes.tschofe...@nsn.com 发件人: *oauth-boun...@ietf.org* oauth-boun...@ietf.org 2012-12-03 16:49 收
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
The intent was definitely not to constrain who/what could be the issuer. But also try to provide some guidance around the common cases that are actually being deployed now, which are the client self-issued and STS variants. Resource owner as an issuer is an interesting case but seems mostly theoretical at this point. I feel like mentioning the resource owner there in §5.1 would cause more confusion than anything else. I'd prefer to just strike the whole sentence in question and maybe add some additional text to §3 that clarifies that the issuer can really be any entity, if folks think a change is needed here? On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura sakim...@gmail.com wrote: Actually, The issuer may be either an OAuth client (when assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. is not really clean. OAuth client is just another example of an issuer. So, perhaps the sentence could be: Example of issuers include an OAuth client, resource owner, an independent third party. So, the clause becomes: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. Example of issuers include an OAuth client, resource owner, an independent third party. Nat Nat On Tue, Dec 4, 2012 at 11:40 AM, zhou.suj...@zte.com.cn wrote: Chuck Mortimore cmortim...@salesforce.com 写于 2012-12-04 10:26:50: Please feel free to suggest better language. Issuer simply allows the token service to know who created the assertion, so it can look them up and see if they're trusted. Effectively the same as an Issuer in SAML. a conflict : The token service is the assertion issuer in assertion document. while you said token service know who created the assertion I wonder if the following text is acceptable: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. The issuer may be either an OAuth client (when assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. 6.3. Client Acting on Behalf of a User The Issuer of the assertion MUST identify the entity that issued the assertion as recognized by the Authorization Server. If the assertion is self-issued, the Issuer SHOULD be the client_id. If the assertion was issued by a Security Token Service (STS), the Issuer SHOULD identify the STS as recognized by the Authorization Server.If the assertion was issued by the resource owner, the Issuer SHOULD identify the resource owner as recognized by the Authorization Server. -cmort On Dec 3, 2012, at 6:23 PM, zhou.suj...@zte.com.cn wrote: Obviously, it is not so clear from the language there. Chuck Mortimore cmortim...@salesforce.com 写于 2012-12-04 10:17:12: There's no reason why it can't be resource owner today. On Dec 3, 2012, at 6:06 PM, zhou.suj...@zte.com.cn zhou.suj...@zte.com.cn wrote: +1. And why it was not looked at that time? oauth-boun...@ietf.org 写于 2012-12-04 01:30:55: Actually, I think it is a good time to start looking at the resourse owner issuing assertions@ (Interestingly enough, Hui-Lan had brought this up a couple of years ago.) Igor On 12/3/2012 3:58 AM, Nat Sakimura wrote: I suppose, yes. I was reading it like that all the time. Whether it is or not, if it is still ok, it might be better to clarify it. Word like third party tends to be a bit of problem without clearlydefining. I had similar experience in other fora. Nat Sent from iPad 2012/12/03 0:52、zhou.suj...@zte.com.cn zhou.suj...@zte.com.cn の メッセ�`ジ: could be Resource owner? Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com 发件人: oauth-boun...@ietf.org 2012-12-03 16:49 收件人 ext Nat Sakimura sakim...@gmail.com, Brian Campbell bcampb...@pingidentity.com, oauth oauth@ietf.org 抄送 主题 Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? Hi Nat, The current text essentially says that the assertion can either be created by the client (in which case it is self-signed) or it can be created by some other entity (which is then called the third party token service). So, this third party could be the authorization server. Ciao Hannes From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Nat Sakimura Sent: Monday, December 03, 2012 10:35 AM To: Brian Campbell; oauth Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to be either
Re: [OAUTH-WG] Review of Assertions drafts
Fixed that one in -15 of the SAML draft. Thanks for the review. FWIW, the requirement about only one client authentication mechanism being used actually comes from core OAuth at http://tools.ietf.org/html/rfc6749#section-2.3 and is worded pretty strongly there where it says, The client MUST NOT use more than one authentication method in each request. On Tue, Nov 6, 2012 at 2:46 PM, Anganes, Amanda L aanga...@mitre.orgwrote: Good catch, thanks for double-checking. --Amanda From: Mike Jones michael.jo...@microsoft.com Date: Tuesday, November 6, 2012 4:40 PM To: Anganes, Amanda L aanga...@mitre.org, oauth@ietf.org oauth@ietf.org Subject: RE: Review of Assertions drafts Amanda wrote: [3] Section 2.2 first sentence: client authentication grant should just be client authentication. ** ** This change should also be applied to the first sentence of 2.2 in SAML draft, where the same phrase occurs. ** ** -- Mike ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.orgoauth-boun...@ietf.org] *On Behalf Of *Anganes, Amanda L *Sent:* Tuesday, November 06, 2012 12:41 PM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Review of Assertions drafts ** ** Hannes requested that some folks read through the assertion drafts and give feedback in light of the upcoming shepherd review. ** ** [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ [2] http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ [3] http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ ** ** I can't speak to the security considerations or advisability of these drafts, but as far as the documents go I think they are well-organized, consistent (internally and across all 3 documents) and straightforward. ** ** ** ** A few comments: ** ** [1] Section 4.2.1 says in passing that it is an error condition if more than one client authentication mechanism is used. If this is a true requirement / error state I think it should be called out more strongly. Perhaps 4.2 should say at the top that Other client authentication mechanisms MUST NOT be used in conjunction with an assertion. ** ** If so, [2] 3.2 and [3] 3.2 should also indicate that additional client credentials MUST NOT be used in addition to the assertion for Client Authentication. ** ** [3] Section 2.2 first sentence: client authentication grant should just be client authentication. ** ** --Amanda Anganes ___ 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] JOSE and JWT specs updated for IETF 85 working group meetings
On the heels of this, I've just published new versions of the Assertion Framework for OAuth 2.0 and SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 that update references to the new RFCs and fix some typos recently identified by folks in the WG. The updated documents are available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-07 http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 On Wed, Nov 7, 2012 at 3:13 AM, Michael Jones michael_b_jo...@hotmail.comwrote: I’ve made a small set of updates to the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the JOSE http://datatracker.ietf.org/wg/jose/charter/ and OAuthhttp://datatracker.ietf.org/wg/oauth/charter/working group meetings at IETF 85 http://www.ietf.org/meeting/85/. These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts.** ** ** Normative changes to the working group specs were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod, xpo) to (n, e). Fields for representing the RSA private key values needed for Chinese Remainder Theorem (CRT) calculations were added to the JSON Private Key specification. ** ** The updated specs are available at: ·http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07* *** ·http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07 ·http://tools.ietf.org/html/draft-ietf-jose-json-web-key-07 ·http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-07 ·http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05 ·http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03 · http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-03 · http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-03 ·http://tools.ietf.org/html/draft-jones-jose-json-private-key-01** ** ** ** HTML formatted versions are available at: · http://self-issued.info/docs/draft-ietf-jose-json-web-signature-07.html*** * · http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-07.html** ** ·http://self-issued.info/docs/draft-ietf-jose-json-web-key-07.html · http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-07.html** ** · http://self-issued.info/docs/draft-ietf-oauth-json-web-token-05.html ·http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-03.html* *** · http://self-issued.info/docs/draft-jones-jose-jws-json-serialization-03.html · http://self-issued.info/docs/draft-jones-jose-jwe-json-serialization-03.html · http://self-issued.info/docs/draft-jones-jose-json-private-key-01.html ** ** See the history entries in the specs for detailed change descriptions. ** ** -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth token entropy
I believe the original text (which was borrowed from elsewhere) had a must followed by a should rather than two shoulds like that. The text seems to have drifted a bit in various places but the threat model text should probably be aligned with what's in core OAuth at http://tools.ietf.org/html/rfc6749#section-10.10 On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb oleg_g...@yahoo.com wrote: Can somebody please provide clarification for this: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2 http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.25.1.4.2.2 http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2. High entropy of secrets... The probability of any two Authorization Code values being identical should be less than or equal to 2^(-128) and should be less than or equal to 2^(-160). Is there any reason why we have two inclusive conditions in this statement or is it a typo and you meant something else? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-assertions-06
As a vendor we can't really share deployment particulars of our customers. But we've had product support for the SAML authorization grant for some time now. So I can point to some online documentation for the support we provide in our PingFederate product as an AS, http://documentation.pingidentity.com/display/PF610/Configuring+an+OAuth+SAML+Grant+IdP+Connectionand http://documentation.pingidentity.com/display/PF610/Grant+Types#GrantTypes-1218708as well client side support for obtaining suitable SAML tokens via WS-Trust or brokering the OAuth request directly to the AS, http://documentation.pingidentity.com/display/PF610/STS+OAuth+Integration Off hand I also remember that Google released some support for JWT grants in March. My colleague, the venerable John Fontana, wrote about that on ZDnet, http://www.zdnet.com/blog/identity/google-dumps-keys-passwords-secures-services-with-standards-certs/342 On Mon, Oct 8, 2012 at 6:14 PM, Chuck Mortimore cmortim...@salesforce.comwrote: Our use-cases are pretty straightforward - customers want to perform server to server integration tasks without passwords. We use the SAML and JWT assertion profiles to enable them to authenticate to our system without having a password for the service principal they're trying to act as. Sometimes this is for security purposes ( customer doesn't want to use passwords ), and sometimes it's for scale purposes ( customer is building some sort of hub-spoke integration architecture where passwords and their associated distribution and maintenance simple won't scale ) While SAML is predominantly used for Web SSO today, it is used and quite applicable in these types of scenarios. The easy way to picture what we're doing is deploying a Security Token Service similar to WS-Trust, but without all the baggage of WS-Trustyou can simply post Assertions to our Token Endpoint and we can exchange that for oauth access tokens. -cmort On Oct 8, 2012, at 5:05 PM, Mike Jones wrote: Yes, OpenID Connect uses the Assertions spec and the JWT Assertion Profile. See uses of [OAuth.JWT] in http://openid.net/specs/openid-connect-messages-1_0.html. It is used for both client_secret_jwt and private_key_jwt client authentication. Per http://osis.idcommons.net/wiki/Category:OC4_Solution, there are a dozen publicly declared OpenID Connect implementations (admittedly some incomplete), and substantial interop testing is under way, per http://osis.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4. ** ** Brian Campbell and Chuck Mortimore may be able to provide similar data for use of the SAML Profile. ** ** -- Mike*** * ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Tschofenig, Hannes (NSN - FI/Espoo) *Sent:* Monday, October 08, 2012 5:13 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] draft-ietf-oauth-assertions-06 ** ** Hi all, I took a look at version -06 of the assertions draft to see whether some of the discussions had been reflected in this recent draft update. I was hoping that there is a bit more explanation of the use case that motivates the work. Unfortunately, the update does not contain anything along these lines. For example, the use cases could clarify the following aspects: · Why we need these new client authentication mechanisms? This is not necessarily a way in which SAML is used (at least not to my knowledge). If I understood it correctly then the new client authentication mechanism is only used between the client and the authorization server but not with the resource server. Did I correctly read the document? · Then, there is the assertion usage for authorization grants. There, one could argue that the use case is to interwork with existing SAML infrastructure. The sameargument does not apply for the JSON based format since there is no transition need (IMHO at least). Ciao Hannes PS: For the shepherd write-up I have to attach information about the implementation and deployment experience. Is there anything I could mention? Has this specification been part of the OpenID Connect interop tests? If so, what specifically had been tested? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth
Thanks Mike! They say you never forget your first RFC... On Thu, Oct 4, 2012 at 5:04 PM, Mike Jones michael.jo...@microsoft.comwrote: Congratulations on completing the first OAuth working group RFC!!! -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of rfc-edi...@rfc-editor.org Sent: Thursday, October 04, 2012 3:30 PM To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org Cc: oauth@ietf.org; rfc-edi...@rfc-editor.org Subject: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth A new Request for Comments is now available in online RFC libraries. RFC 6755 Title: An IETF URN Sub-Namespace for OAuth Author: B. Campbell, H. Tschofenig Status: Informational Stream: IETF Date: October 2012 Mailbox:brian.d.campb...@gmail.com, hannes.tschofe...@gmx.net Pages: 5 Characters: 8336 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-oauth-urn-sub-ns-06.txt URL:http://www.rfc-editor.org/rfc/rfc6755.txt This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Web Authorization Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html . For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] New assertion drafts published
New versions of the three OAuth assertion related drafts have been published. The documents are available in the usual locations: Assertion Framework for OAuth 2.0 http://tools.ietf.org/html/draft-ietf-oauth-assertions-06 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-14 JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-02 Text was added to the introduction of all three further explaining that an assertion grant type can be used with or without client authentication/identification and that client assertion authentication is nothing more than an alternative way for a client to authenticate to the token endpoint. Two new examples were added to each of the JWT and SAML drafts. References were updated in all three. Hopefully now draft-ietf-oauth-assertions-06 and draft-ietf-oauth-saml2-bearer-14 are ready to go to WGLC. Thanks to Mike Jones for the preliminary review and updates/fixes. Regards, Brian Campbell ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed additions to clarify authz and/or authn usage with assertions
The last sentence is intended to say that any form of client authentication that the AS supports (including none) can be used with an assertion grant. It's a general policy statement and doesn't mean that more than one type of client authentication can be used in a single request. That The client MUST NOT use more than one authentication method in each request and other requirements from draft-ietf-oauth-v2 still apply. Could this be worded differently to be more clear? On Thu, Sep 13, 2012 at 4:26 AM, Willem van Engen wvengen+oau...@nikhef.nl wrote: On 12-09-12 21:58, Brian Campbell wrote: Client assertion authentication is nothing more than an alternative way for a client to authenticate to the token endpoint and must be used in conjunction with some grant type to form a complete and meaningful protocol request. Assertion authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with an assertion authorization grant, as well as the supported types of client authentication, are a policy decisions at the discretion of the authorization server. The last sentence appears to leave some space for client assertion authentication to be used with other forms of client authentication. Is this intended, as it appears to go contrary to The client MUST NOT use more than one authentication method in each request in [1] ? Regards, - Willem [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-2.3 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Informal OAuth Chat @ IETF#84
Is there any consensus about this? On Mon, Jul 30, 2012 at 2:49 PM, Leif Johansson le...@mnt.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2012 10:43 PM, Phil Hunt wrote: I can't do it before 5 Maybe find another day Hannes? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAW814ACgkQ8Jx8FtbMZndKcwCeLgJdj4EEZOtmrStdXzCHaVXf exQAn2PQ//shnMa86u1YOEHrnC193UBJ =/Jyp -END PGP SIGNATURE- ___ 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] Proposed note to RFC Editor
Hey Torsten, The requirement that public clients send their client_id with an authz code grant is in 4.1.3 (Where the Access Token Request for the code grant is defined) of John's proposed text: 4.1.3. Access Token Request client_id REQUIRED if the client is NOT authenticating with the authorization server as described in Section 3.2.1 On Thu, Jul 26, 2012 at 11:40 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi John, I would expect sending a client_id is a MUST for public clients in the authz code grant type. That's not how I read the proposed text for section 3.1. regards, Torsten. John Bradley ve7...@ve7jtb.com schrieb: The changes introduced in Draft 29 had unintended consequences on parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication. This change restricts the requirement to send client_id to only Sec 4.1.4 for clients that are not authenticated per Sec 3.2.1 Section 3.2.1 A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint. This allows the authorization server to ensure that the code was issued to the same client. Sending client_id prevents the client from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) Change to A client MAY use the client_id request parameter to identify itself when sending requests to the token endpoint. In the authorization_code grant_type request to the token endpoint, an unauthenticated client sends client_id to prevent itself from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) ** This allows any client to send client ID and explains the threat to code. 4.1.3. Access Token Request Add client_id REQUIRED if the client is NOT authenticating with the authorization server as described in Section 3.2.1 ** This makes client_id only REQUIRED for the code flow if the client is not otherwise authenticated. Change ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request, To: ensure the authorization code was issued to the authenticated confidential client, or if the client is public, ensure the code was issued to client_id in the request, ** That removes the implication of authentication. ___ 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] Proposed note to RFC Editor
Fair enough. I read 3.2.1 as being more informative and explanatory while 4.1.3 has the actual normative requirements. But I see what you are saying too. On Fri, Jul 27, 2012 at 8:36 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Brian, I know. But there is this sentence in 3.2.1, -- In the authorization_code grant_type request to the token endpoint, an unauthenticated client sends client_id to prevent itself from inadvertently accepting a code intended for a client with a different client_id. --- which explicitely discusses the authz code w/o saying this behavior is mandatory. People might feel a contradiction or difference to 4.1.3. I would suggest to either remove this sentence in 3.2.1 or change it to: -- In the authorization_code grant_type request to the token endpoint, an unauthenticated client MUST send its client_id to prevent itself from inadvertently accepting a code intended for a client with a different client_id. --- regards, Torsten. Am 27.07.2012 15:47, schrieb Brian Campbell: Hey Torsten, The requirement that public clients send their client_id with an authz code grant is in 4.1.3 (Where the Access Token Request for the code grant is defined) of John's proposed text: 4.1.3. Access Token Request client_id REQUIRED if the client is NOT authenticating with the authorization server as described in Section 3.2.1 On Thu, Jul 26, 2012 at 11:40 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi John, I would expect sending a client_id is a MUST for public clients in the authz code grant type. That's not how I read the proposed text for section 3.1. regards, Torsten. John Bradley ve7...@ve7jtb.com schrieb: The changes introduced in Draft 29 had unintended consequences on parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication. This change restricts the requirement to send client_id to only Sec 4.1.4 for clients that are not authenticated per Sec 3.2.1 Section 3.2.1 A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint. This allows the authorization server to ensure that the code was issued to the same client. Sending client_id prevents the client from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) Change to A client MAY use the client_id request parameter to identify itself when sending requests to the token endpoint. In the authorization_code grant_type request to the token endpoint, an unauthenticated client sends client_id to prevent itself from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) ** This allows any client to send client ID and explains the threat to code. 4.1.3. Access Token Request Add client_id REQUIRED if the client is NOT authenticating with the authorization server as described in Section 3.2.1 ** This makes client_id only REQUIRED for the code flow if the client is not otherwise authenticated. Change ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request, To: ensure the authorization code was issued to the authenticated confidential client, or if the client is public, ensure the code was issued to client_id in the request, ** That removes the implication of authentication. ___ 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] overreach of the scope of when client_id is required from public clients?
Yes, the intent is to allow totally anonymous clients. There are cases where that is very useful and where user revocation isn't applicable (i.e. only an access token is issued). The changes in -29 were introduced to protect clients against authorization code substitution. Those changes are breaking changes to the code flow (in some cases) but it was felt that the security benefits warranted the change even this late in the process. However, by placing that text in §3.2.1, and having it apply to all requests to the token endpoint, the change impacts a lot more than just the authorization code grant and introduces breaking changes to functionality not subject to the authorization code substitution issue that the change was made to address. That inadvertent breaking changes isn't just theoretical either. It breaks https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ - see the example at the end of section 4 of each for requests to the token endpoint that legitimately have no client identification. The change also breaks features that have been available in our product for nearly a year (and presumably other products/services implementations as well). I realize it's late in the process to bring this up but the aforementioned change was also introduced very late and had a broader impact than what was intended. I'd strongly suggest that the text in the last paragraph of §3.2.1 be moved (and slightly adjusted for context) into §4.1.3 right after, or as part of, the paragraph about client authentication. And the the last paragraph of §3.2.1 should be reverted to what it was in -28. At this stage I don't know how that kind of thing is best handled - an RFC editor note? But I believe it needs to be taken care of somehow before publication. Thanks, Brian On Wed, Jul 25, 2012 at 4:21 PM, John Bradley ve7...@ve7jtb.com wrote: The client_id of a public client is self asserted in the request to the token endpoint, the authorization server can reject it if it is wrong without relying on it to be correct. I agree that the word identify in both places seems like a contradiction on the surface. 4.1.3 could be softened from 'identified by' to 'indicated by' For your first point, are there public clients without client_id? If so how would a user revoke access? One reading of 4.3 step c is that the server must authenticate the client. If the intent really is to allow totally anonymous clients then I see your point. Thoughts from others? John B. Sent from my iPad On 2012-07-25, at 12:07 PM, Brian Campbell bcampb...@pingidentity.com wrote: In -29 the quoted text below was introduced to §3.2.1 Client Authentication [1] to protect clients against authorization code substitution. However, the text's placement under 3.2. Token Endpoint [2] and some of the wording suggest that public clients must use client_id on all requests to the token endpoint, regardless of grant type, even though the change was introduced only to mitigate an issue with the authentication code. A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint. This allows the authorization server to ensure that the code was issued to the same client. Sending client_id prevents the client from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) Was the change intended to be that broad? I think it goes too far. There are cases, like extension grants and even the resource owner credentials grant type, where it's useful to allow requests from unidentified clients. Could that text (or the spirit of it) be moved somewhere under the specific sections on the Authorization Code Grant so that it only applies to that grant type? A somewhat related issue is the following text from §2.3. Client Authentication the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client. which seems to contradict the text from §3.2.1 above as well as the following from 4.1.3. Access Token Request [3] o ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request, Should the text in §2.3 be loosened or somehow qualified so it doesn't read like a contradiction? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2.1 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2 [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-2.3 [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-4.1.3 ___ OAuth mailing list
Re: [OAUTH-WG] Proposed note to RFC Editor
I agree with the proposed changes and they do adequately address the concerns I raised in a previous message about the unintended breaking changes introduced in 29. Thanks for writing that up John. On Thu, Jul 26, 2012 at 2:33 PM, John Bradley ve7...@ve7jtb.com wrote: The changes introduced in Draft 29 had unintended consequences on parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication. This change restricts the requirement to send client_id to only Sec 4.1.4 for clients that are not authenticated per Sec 3.2.1 Section 3.2.1 A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint. This allows the authorization server to ensure that the code was issued to the same client. Sending client_id prevents the client from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) Change to A client MAY use the client_id request parameter to identify itself when sending requests to the token endpoint. In the authorization_code grant_type request to the token endpoint, an unauthenticated client sends client_id to prevent itself from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) ** This allows any client to send client ID and explains the threat to code. 4.1.3. Access Token Request Add client_id REQUIRED if the client is NOT authenticating with the authorization server as described in Section 3.2.1 ** This makes client_id only REQUIRED for the code flow if the client is not otherwise authenticated. Change ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request, To: ensure the authorization code was issued to the authenticated confidential client, or if the client is public, ensure the code was issued to client_id in the request, ** That removes the implication of authentication. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Clarification enhancement for saml2 bearer spec
I'm really inclined to keep it such that that is an option. We've got product features that allow for it an assertion grant to be used alone now and I think they are really useful in some cases. And I think this use case is different enough from the authorization code situation that the fix for the code swapping there doesn't really apply here. Just one point of clarification: when an assertion is used as a grant alone with no client identification or authentication, the assertion doesn't authenticate the client. The client is anonymous. The issuer of the assertion may give some clues about the client or the security domain of the client. But it doesn't necessarily directly identify the client. Sorry (as usual) for the delayed response. And I've still got it on my queue to propose some new text for the points of confusion you raised in the beginning of this thread. On Tue, Jul 3, 2012 at 3:47 PM, Phil Hunt phil.h...@oracle.com wrote: On 2012-07-03, at 2:12 PM, Brian Campbell wrote: Thanks for the feedback Phil. In the case of §2.1, Using SAML Assertions as Authorization Grants the intent was to allow for such a SAML grant to be used with or without client authentication. Whether or not client authentication is required (and what type of authentication) would be a deployment/policy decision of the AS. But both are possible from the spec. Yes. This makes sense. However in light of the recent discussion about bearer codes and tokens I'm a little more nervous of convolving the grant and client authentication together. It's really the token server that should properly authenticate the client and obscuring that act by combining in a single grant may serve to confuse. There is also the issue of offering too many choices. Just an opinion, but I can live with your suggestion that grant can be used alone. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] overreach of the scope of when client_id is required from public clients?
In -29 the quoted text below was introduced to §3.2.1 Client Authentication [1] to protect clients against authorization code substitution. However, the text's placement under 3.2. Token Endpoint [2] and some of the wording suggest that public clients must use client_id on all requests to the token endpoint, regardless of grant type, even though the change was introduced only to mitigate an issue with the authentication code. A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint. This allows the authorization server to ensure that the code was issued to the same client. Sending client_id prevents the client from inadvertently accepting a code intended for a client with a different client_id. This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) Was the change intended to be that broad? I think it goes too far. There are cases, like extension grants and even the resource owner credentials grant type, where it's useful to allow requests from unidentified clients. Could that text (or the spirit of it) be moved somewhere under the specific sections on the Authorization Code Grant so that it only applies to that grant type? A somewhat related issue is the following text from §2.3. Client Authentication the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client. which seems to contradict the text from §3.2.1 above as well as the following from 4.1.3. Access Token Request [3] o ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request, Should the text in §2.3 be loosened or somehow qualified so it doesn't read like a contradiction? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2.1 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2 [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-2.3 [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-4.1.3 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Change in editorship of OAuth Core Spec
+1 Well said Justin. And thank you Eran. On Mon, Jul 23, 2012 at 11:05 AM, Richer, Justin P. jric...@mitre.org wrote: Eran Hammer has decided to step down as Editor of the OAuth Core specification. I would like to personally thank Eran for all his years of hard work and effort to the draft as well as to the working group at large. As former chair, I want to add my thanks. Eran has done a *lot* of work on the OAuth documents over the last years, and deserves much appreciation for it. Late to the party, but I also want to publicly thank Eran for what has been a nearly thankless job over the last few years. It's very difficult wrangling a pack of angry nerds and trying to express a group consensus, to be sure. In the end I think we have a specification document that is readable, makes sense, and will ultimately be one of the most useful protocols on the internet over the next few years. I know it hasn't been easy, and things probably could have gone a lot better than they did, but even still: Thank you. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-06.txt
Draft -06 of An IETF URN Sub-Namespace for OAuth has been published. The only changes in this draft are to address editorial comments made in the Gen-ART LC Review at http://www.ietf.org/mail-archive/web/gen-art/current/msg07576.html - the comment was a typo (from should be form) rather than a missing word. Thanks, Brian -- Forwarded message -- From: internet-dra...@ietf.org Date: Mon, Jul 16, 2012 at 11:41 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-06.txt To: i-d-annou...@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : An IETF URN Sub-Namespace for OAuth Author(s) : Brian Campbell Hannes Tschofenig Filename: draft-ietf-oauth-urn-sub-ns-06.txt Pages : 7 Date: 2012-07-16 Abstract: This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-urn-sub-ns-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-saml2-bearer-13.txt
Draft -13 of the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 document has been published. This draft includes only the minor changes listed below. draft-ietf-oauth-saml2-bearer-13 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth -28 o Changed Description to Specification Document in both registration requests in IANA Considerations per changes to the template in ietf-oauth-urn-sub-ns(-03) o Added (or an acceptable alias) so that it's in both sentences about Recipient and the token endpoint URL so there's no ambiguity o Update area and workgroup (now Security and OAuth was Internet and nothing) Thanks, Brian -- Forwarded message -- From: internet-dra...@ietf.org Date: Tue, Jul 3, 2012 at 7:12 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-13.txt To: i-d-annou...@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Filename: draft-ietf-oauth-saml2-bearer-13.txt Pages : 17 Date: 2012-07-03 Abstract: This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-13 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-saml2-bearer-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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] Clarification enhancement for saml2 bearer spec
Thanks for the feedback Phil. In the case of §2.1, Using SAML Assertions as Authorization Grants the intent was to allow for such a SAML grant to be used with or without client authentication. Whether or not client authentication is required (and what type of authentication) would be a deployment/policy decision of the AS. But both are possible from the spec. In the case of §2.2, Using SAML Assertions for Client Authentication, yes it's just providing an alternative method of client authentication beyond what's specified in §2.3 of core. It doesn't really do anything on its own and must be used in conjunction with the grant_type parameter. I'll take a stab at some clarifying text and/or examples for those points of confusion. Suggestions are, of course, welcome too. On Tue, Jul 3, 2012 at 1:15 PM, Phil Hunt phil.h...@oracle.com wrote: I have had a couple developers get confused by sections 2.1 and 2.2 of the spec. What seems to be happening is they read them as distinct complete flows rather then considering the core spec still applies. In the case of 2.1, Using SAML Assertions as Authorization Grants they forget that a client credential is also needed and only specify the SAML authorization assuming it includes both (which may or may not be intended). In the case of 2.2, Using SAML Assertions for Client Authentication, they are not making the link that the client authentication may be used in connection with any of the OAuth flows. They are instead treating this as a new flow. IOW they forget to add the grant_type parameter. It might be helpful to include complete examples for each of 2.1 and 2.2 to clarify. Phil @independentid www.independentid.com phil.h...@oracle.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Published -04 of Assertion Framework for OAuth 2.0
Draft -04 of the Assertion Framework for OAuth 2.0 (now with a new name!) has been published. This draft includes significant changes that attempt to incorporate comments and proposed new text from the document shepherd[1]. The new draft is available at http://tools.ietf.org/html/draft-ietf-oauth-assertions-04 as well as the other usual locations. Thanks, Brian [1] the main thread is at http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03
Hi Hannes, Near the end of §1 of your draft -04 you discuss client authentication with the Resource Server by saying that the client authentication concerns steps (E) and (F) in figure 1. However, my reading of §2.3 of the core OAuth Framework[1] was that only client authentication to the AS was in scope for the spec. Following from that, my assumption and intent with the assertion spec was that client assertion authentication is only defined for a client authenticating to the token endpoint of an AS. §3 of the -03 of the assertions doc[2] even says, This specification provides a model for using assertions for authentication of an OAuth client during interactions with an Authorization Server. Was there something in the -03 draft (or the core spec for that matter) that suggested it was intended for client to RS authentication? I don't think specifying that (other than in defining how an access token is presented like draft-ietf-oauth-v2-bearer does) that would be appropriate. Maybe some clarification is needed? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-2.3 [2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-3 On Sun, Jun 24, 2012 at 7:42 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Brian, thanks for your response. I have tried to put additional text into version -04 of the draft to address my earlier comments. The most recent version of the updated document is there: https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.txt Here is the XML: https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.xml It took me a little while to make these changes, as you can imagine. I hope I was able to improve the quality and clarity of the document. I still have to respond to your second mail about the relaxed usage of the RFC 2119 language. Will do that asap. Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth URN Registry Discussion Summary
I concur. RFC 3553 does say the colon character (:) is used to denote a very limited concept of hierarchy and the current text in -04 uses the colon consistent with that limited concept of hierarchy. However, as Mike already said, the intent of http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns is that it be a general naming convention and not something that need be part of the registry. On Sat, Jun 23, 2012 at 12:41 PM, Mike Jones michael.jo...@microsoft.com wrote: I'd rather that we did the review based upon the current draft rather than rolling back. Hannes, my point about three levels was that we can't necessarily know up front what the structure of URNs would be that might make sense to register in the future. I was using that possibility as an example to object to a strict two-level hierarchy. Sometimes a one-level name may make sense as well. I agree with you that Section 3 of http://tools.ietf.org/html/rfc3553 says about the colon character (:) defines a lightweight syntax for hexarchies to use when they make sense. I just think it's overkill to put the hierarchy in the registry, per se. I agree that in http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions we should add IANA considerations text saying that any new extensions for client assertions should be registered with the name client-assertion-type:*. Likewise we should figure out the right place to say that new grant types should be registered as grant-type:*. These would be naming conventions though - not something that's a part of the registry. Cheers, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, June 23, 2012 8:17 AM To: OAuth WG Subject: [OAUTH-WG] OAuth URN Registry Discussion Summary As you have seen I have responded to various mails and I believe I understand what people want. Some of you obviously have plans to write extensions (in other organizations outside the IETF, and as vendor-specific extensions). That's fine. You want something really lightweight (in terms of process) that does not require you to come to the IETF to write an RFC and get the entire working group excited about your hobby project. Clearly, this makes sense to me. So, the policy for adding new extensions has to be either 'Specification Required' or 'Expert Review' with the difference being about the information that goes into the registry. For the cases I have seen on the list it will not make a huge difference. It may make a difference for an organization where their final specifications are not publically available. Yes, these organizations still exist today Then, there is the question about how the identifier that gets registered should look like. You seem to like the idea of concept of a structured identifier (since otherwise you wouldn't be using it in various working group drafts already, including the example in draft-ietf-oauth-urn-sub-ns itself!) but you don't like to call it hierarchy because you fear that you will not be allowed to do whatever you want. An unjustified concern. In that sense version -03 of the draft (see http://tools.ietf.org/id/draft-ietf-oauth-urn-sub-ns-03.txt) pretty much does already everything you want already do. As a policy it says Expert Review and it has the structure in the ID that you guys are using in your current drafts! There are two options to go forward. The first one is to roll-back to version -03. Another option is to take version -04 and add text that explains the id a bit further by saying that it may contain a structure and other documents populating the registry will define the detailed structure of the id part. In http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ we would then add a section to the IANA consideration section saying that any new extensions for client assertions needs to be registered under urn:ietf:params:oauth:client-assertion-type: The same for urn:ietf:params:oauth:grant-type: in some other document and so on. Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt
Unless there are objections from the WG, I'd like to publish -04 today with two smallish changes (new text listed below) to address the question raised yesterday in http://www.ietf.org/mail-archive/web/oauth/current/msg09381.html and have -04 be the draft for LC. First paragraph of §3: If a registrant wishes to have a OAuth URI registered, then a URN of the form urn:ietf:params:oauth:value will be requested where value is a suitable representation of the functionality or concept being registered. Index value bullet of §5.1 Index value: values subordinate to urn:ietf:params:oauth are of the from urn:ietf:params:oauth:value with value as the index value. It is suggested that value include both a class and an identifier-within-class component, with the two components being separated by a colon (:); other compositions of the value may also be used. Thanks, Brian On Fri, Jun 22, 2012 at 6:06 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: I'll wait until the chairs tell me what you want but I'm fine with doing the IETF LC on -03 now, or with waiting if the chairs reckon that's better. So just let me know. Cheers, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] issues with §8.3 grant type parameters? (was ... draft-ietf-oauth-urn-sub-ns-03.txt)
It was a design decision that seemed most appropriate given the various factors and goals of my application at the time. My goal in pointing to that was not to elicit feedback on the design itself but to show that 'vendor-specific' extension grants will happen, and already have happened, and that that might suggest a problem with the text in §8.3 of the core spec. Do others see an issue here? http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 We can discuses the merits of the introspection as a grant type approach if/when the WG chooses to take that on as a work item and to the extent that approach is of interest. My colleague posted an early/rough draft of that approach as an attachment to http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html On Fri, Jun 22, 2012 at 12:09 AM, Manger, James H james.h.man...@team.telstra.com wrote: In fact, I've already got a vendor-specific grant type that uses an unregistered parameter on the token endpoint - it's a simple grant type for access token introspection [2]. [2] http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameter s#GrantTypeParameters-1079271 Why are you trying to overload this new functionality onto a URI used for other purposes? Why not just pick a URI specifically for your purpose, eg /as/validate? -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] -03 IETF URN Sub-Namespace for OAuth published
An IETF URN Sub-Namespace for OAuth draft -03 has been published and is available at http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 Changes (listed below as well as in the document history) from the previous version were made in response to AD review and the subsequent discussion prompted by that review. The intent of the document remains unchanged (to create and register an IETF URN Sub-namespace of urn:ietf:params:oauth and allow OAuth related specs to establish and use URIs underneath it) but the actual text in the doc has changed significantly. So additional review (particularly by those involved in the discussion yesterday) would be very much appreciated. draft-ietf-oauth-urn-sub-ns-03 changes: o Changes to address comments in the message AD review of draft-ietf-oauth-urn-sub-ns-02 at http://www.ietf.org/mail-archive/web/oauth/current/msg09350.html and subsequent messages in that thread o Update area and workgroup (now Security and OAuth was Internet and nothing) o Change from informational to standards-track o Requesting new URNs now more lightweight by changing from 'RFC Required' to 'Expert Review' (RFC5226) o Rework much of the document to be more clear about it registering the urn:ietf:params:oauth URN sub-namespace and separately how other documents are to request URNs under that sub-namespace. o Removed everything about asking the IANA to generate any part of the URN. o Added an Example Registration Request o Added reference to OAuth security considerations in security considerations. o Added Acknowledgements Thanks, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
Thanks Stephen (also Peter) for the review and feedback. Responses are inline. On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi, Many thanks for a nice short document! If only they could all be so short right? :) I've a few questions though and suspect that a quick re-spin might be needed, but let's see what the wg think about 'em first. (1) Why Informational? Everything else at that level seems to be specified in a standards track or BCP level RFC, and IETF Consensus is required. [1] I think you have to do this as standards track. Did I miss something? I'm pretty sure that was just an oversight when using some boilerplate xml to get the document started. I agree with you and Peter that standards track makes more sense and I've updated my local copy of the source to reflect that. (2) Do you *really* want RFC or specification required for all registrations? I don't care, but there is a trend away from that at the moment since its been found to discourage registrations in a lot of cases. Perhaps expert review would be ok? No trying to push you one way or the other, I just wanted to check. Again I agree with you and Peter - lighter is preferred. Though Hannes wrote the original text for this so I'd ask that he please speak up if there was some reason to require RFC here that we aren't aware of. Can you help me with the proper text for this? Is it sufficient to drop the NOTE: in order for a URN of this type to be assigned, the item being registered MUST be documented in a RFC text from the 1st paragraph of §3 and change New entries to the registry are Specification Required to New entries to the registry require expert review in §5.1? (3) If answer to (2) is yes: Section 5.1 says Specification Required but section 3 said RFC Required and those differ. For example, an OASIS spec would not be ok if you say RFC required. I don't know if you care, but you need to be consistent. (Or else I've misread something;-) Having chaired an OASIS TC for 2 years I probably should care :) See the previous comment/question about relaxing this. Expert review seems good or maybe Specification Required but not RFC Required. Regardless, your are right, it should at very least be consistent :) (4) Isn't the template missing the reference to the RFC or other specification that defines the URN? I believe the Description portion of the template was intended to capture that. Or that's how it's kinds been used by specs that use it anyway. Should we add a Specification document(s): to the template? (5) I don't get section 3, sorry;-) Can you give an example of a class:id pair that'd be registered? http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6 and http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-00#section-6 are real examples that *hopefully* do the registration correctly. Do you think I should add an example registration directly to draft-ietf-oauth-urn-sub-ns? Asking IANA to generate the id part seems odd. Agreed. The please assign text should probably be removed. It's really up to the defining spec to say what the class and id are/ nits: s3: s/generally referred/generally known/ Will do. s4: Might be worth pointing at the security considerations section of draft-ietf-oauth-v2? I'd say that text would be good to have read to know about the security considerations for the use of these URNs, before you go making one up. Is just referencing it sufficient? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed URN for JWT token type: urn:ietf:params:oauth:token-type:jwt
I agree that context does sufficiently differentiate. I guess I'm just lamenting the way that type has been overloaded in the base OAuth stuff and am already dreading the conversions that might go something like, well which type of token type are we talking about here? This particular URN probably doesn't change that one way or the other and I'm okay with what you've proposed. I just felt compelled to mention the potential confusion point. On Tue, May 1, 2012 at 6:39 PM, Mike Jones michael.jo...@microsoft.com wrote: I understand what you're saying, but I still believe that the URN is the correct one. While I agree that the potential for confusion is unfortunate, context will actually successfully differentiate the two uses of similar terms. Bear in mind that the OAuth usage of the term is actually short for Access Token Type (see OAuth Core sections 8.1 and 11.1), whereas the URN above is to provide a type identifier for a particular kind of security token. I also believe that the examples in the Bearer spec (see http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-4), the MAC spec (see http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01#section-5.1), and the JWT spec will make the uses of these terms clear to implementers in context. -- Mike -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Tuesday, May 01, 2012 4:26 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed URN for JWT token type: urn:ietf:params:oauth:token-type:jwt The only concern I might raise with it is that use of the token-type part might lead to some confusion. The term token type and the parameter token_type are already pretty loaded and have specific meaning from the core OAuth framework: http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-7.1 That token type is about providing the client with the information required to successfully utilize the access token to make a protected resource request (i.e. mac and bearer) and is not about the structure of the token itself which is what this URI seems to want to describe. JWTs are usually thought of as bearer type tokens but might someday have HoK (http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120430/001860.html) or mac like constructs. I don't think there's really a problem with name collisions here but I think that the current use of token type in the frame work spec is already the cause of some confusion and I'd hate to exacerbate that. On Tue, May 1, 2012 at 5:04 PM, Mike Jones michael.jo...@microsoft.com wrote: I'm editing the JWT spec to prepare for the OAuth WG version and to track changes in the JOSE specs. Currently the typ values defined for JWT tokens are JWT and http://openid.net/specs/jwt/1.0; (see http://tools.ietf.org/html/draft-jones-json-web-token-08#section-5). I believe that the URN value should be changed to use a URN taken from the OAuth URN namespace urn:ietf:params:oauth (defined in http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02). I propose to use the URN: urn:ietf:params:oauth:token-type:jwt I believe this fits well with the other four uses of this namespace to date: urn:ietf:params:oauth:grant-type:saml2-bearer urn:ietf:params:oauth:client-assertion-type:saml2-bearer urn:ietf:params:oauth:grant-type:jwt-bearer urn:ietf:params:oauth:client-assertion-type:jwt-bearer (The first two are from http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-11. The latter two are from http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04.) Do people agree with this URN choice? Thanks, -- Mike ___ 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] Proposed URN for JWT token type: urn:ietf:params:oauth:token-type:jwt
The only concern I might raise with it is that use of the token-type part might lead to some confusion. The term token type and the parameter token_type are already pretty loaded and have specific meaning from the core OAuth framework: http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-7.1 That token type is about providing the client with the information required to successfully utilize the access token to make a protected resource request (i.e. mac and bearer) and is not about the structure of the token itself which is what this URI seems to want to describe. JWTs are usually thought of as bearer type tokens but might someday have HoK (http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120430/001860.html) or mac like constructs. I don't think there's really a problem with name collisions here but I think that the current use of token type in the frame work spec is already the cause of some confusion and I'd hate to exacerbate that. On Tue, May 1, 2012 at 5:04 PM, Mike Jones michael.jo...@microsoft.com wrote: I’m editing the JWT spec to prepare for the OAuth WG version and to track changes in the JOSE specs. Currently the “typ” values defined for JWT tokens are “JWT” and “http://openid.net/specs/jwt/1.0” (see http://tools.ietf.org/html/draft-jones-json-web-token-08#section-5). I believe that the URN value should be changed to use a URN taken from the OAuth URN namespace urn:ietf:params:oauth (defined in http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02). I propose to use the URN: urn:ietf:params:oauth:token-type:jwt I believe this fits well with the other four uses of this namespace to date: urn:ietf:params:oauth:grant-type:saml2-bearer urn:ietf:params:oauth:client-assertion-type:saml2-bearer urn:ietf:params:oauth:grant-type:jwt-bearer urn:ietf:params:oauth:client-assertion-type:jwt-bearer (The first two are from http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-11. The latter two are from http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04.) Do people agree with this URN choice? Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Draft -11 and OAuth 2.0 Assertion Profile Draft -02
Draft -11 of SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 and draft -02 of OAuth 2.0 Assertion Profile have been published. The changes address comments raised during WGLC on the two documents that ended earlier this week. A summary of changes is included (with links to the comment in the mail archive when appropriate) in the document history section of each draft. A copy of the relevant portion of the history is also copied to the bottom of this message for convenience. I'd like to specifically thank Mike Jones for his assistance in getting these updates posted quickly. The drafts are available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-11 http://tools.ietf.org/html/draft-ietf-oauth-assertions-02 draft-ietf-oauth-saml2-bearer-11 o Removed text about limited lifetime access tokens and the SHOULD NOT on issuing refresh tokens. The text was moved to draft-ietf-oauth-assertions-02 and somewhat modified per http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. o Fixed typo/missing word per http://www.ietf.org/mail-archive/web/oauth/current/msg08733.html. o Added Terminology section. draft-ietf-oauth-assertions-02 o Added text about limited lifetime ATs and RTs per http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. o Changed the line breaks in some examples to avoid awkward rendering to text format. Also removed encoded '=' padding from a few examples because both known derivative specs, SAML and JWT, omit the padding char in serialization/encoding. o Remove section 7 on error responses and move that (somewhat modified) content into subsections of section 4 broken up by authn/authz per http://www.ietf.org/mail-archive/web/oauth/current/msg08735.html. o Rework the text about MUST validate ... in order to establish a mapping between ... per http://www.ietf.org/mail-archive/web/oauth/current/msg08872.html and http://www.ietf.org/mail-archive/web/oauth/current/msg08749.html. o Change The Principal MUST identify an authorized accessor. If the assertion is self-issued, the Principal SHOULD be the client_id in 6.1 per http://www.ietf.org/mail-archive/web/oauth/current/msg08873.html. o Update reference in 4.1 to point to 2.3 (rather than 3.2) of oauth-v2 (rather than self) http://www.ietf.org/mail-archive/web/oauth/current/msg08874.html. o Move the Section 3 of out of the xref to hopefully fix the link in 4.1 and remove the client_id bullet from 4.2 per http://www.ietf.org/mail-archive/web/oauth/current/msg08875.html. o Add ref to Section 3.3 of oauth-v2 for scope definition and remove some then redundant text per http://www.ietf.org/mail-archive/web/oauth/current/msg08890.html. o Change The following format and processing rules SHOULD be applied to The following format and processing rules apply in sections 6.x to remove conflicting normative qualification of other normative statements per http://www.ietf.org/mail-archive/web/oauth/current/msg08892.html. o Add text the client_id must id the client to 4.1 and remove similar text from other places per http://www.ietf.org/mail-archive/web/oauth/current/msg08893.html. o Remove the MUST from the text prior to the HTTP parameter definitions per http://www.ietf.org/mail-archive/web/oauth/current/msg08920.html. o Updated examples to use grant_type and client_assertion_type values from the OAuth SAML Assertion Profiles spec. -- Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] double normative? (draft-ietf-oauth-assertions WGLC comment V)
I just noticed that there is a similar situation in §4.1* and 4.2** where there's a MUST before defining the HTTP parameters but some of the individual parameters are marked as OPTIONAL. The MUST should probably be dropped. * http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.1 ** http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2 On Mon, Apr 23, 2012 at 3:26 PM, Brian Campbell bcampb...@pingidentity.com wrote: Sections 6.1, 6.2, 6.3 and 6.4 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 are all similar in that they have a paragraph at the top that ends with, The following format and processing rules SHOULD be applied: followed by a bullet list of specific rules. However some of the individual bullets themselves have normative language including several that have a MUST. On rereading the draft today, I found this to be a little confusing. I mean, what does it mean to say that you SHOULD MUST do something? At a minimum, it seems like kind of bad form. I'm thinking that the lead in text before each list should just say something like The following format and processing rules are to be applied: to avoid any potential logical conflict between the normative terms. But depending on how the previous text was interpreted, that could be considered a breaking change? That might be okay though as this is just an abstract specification. Any thoughts? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on Assertion Drafts
Just a note (to myself as much as anything) that that same text is also in §6.2, §6.3 §6.4 and should updated for all occurrences. On Fri, Apr 13, 2012 at 12:55 PM, Zeltsan, Zachary (Zachary) zachary.zelt...@alcatel-lucent.com wrote: Chuck, ** ** The intent is clear. Perhaps the following change would clarify the text:* *** Old: The Authorization Server MUST validate the assertion in order to establish a mapping between the Issuer and the secret used to generate the assertion. New: The Authorization Server MUST validate the assertion’s signature in order to verify the Issuer of the assertion. ** ** Zachary ** ** ** ** *From:* Chuck Mortimore [mailto:cmortim...@salesforce.com] *Sent:* Friday, April 13, 2012 1:20 PM *To:* Zeltsan, Zachary (Zachary); Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org *Subject:* Re: [OAUTH-WG] WGLC on Assertion Drafts ** ** Hi Zachary – sorry about the delay in responding. Perhaps the language is a bit confusing – let me explain the intent and see if it makes sense and if you have a recommendation on how it could be made clearer. All this is really saying is that the Authorization server must validate the signature to make sure the Issuer is who they say they are. The authorization server would use the Issuer as it’s mechanism for looking up either the shared secret for an HS256 or the public key for RS256. It then checks the signature, and proves to itself that the generator of the assertion had possession of the expected keying material and identified itself as the issuer. Feedback welcome -cmort On 4/5/12 1:33 PM, Zeltsan, Zachary (Zachary) zachary.zelt...@alcatel-lucent.com wrote: Hello, The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01, section 6.1 has the following requirement: The Authorization Server MUST validate the assertion in order to establish a mapping between the Issuer and the secret used to generate the assertion. I thought that checking a signature is a part of the assertion validation, which cannot be done without knowing the mapping between the issuer and the secret used to generate the assertion. It appears that the quoted text requires validation of the assertion prior to checking the signature. What am I missing? Zachary *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.orgoauth-boun...@ietf.org] *On Behalf Of *Tschofenig, Hannes (NSN - FI/Espoo) *Sent:* Thursday, April 05, 2012 10:47 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] WGLC on Assertion Drafts Hi all, this is a Last Call for comments on these three documents: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02 Please have your comments in no later than April 23rd. Do remember to send a note in if you have read the document and have no other comments other than it’s ready to go - we need those as much as we need I found a problem. Thanks! Hannes Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-assertions WGLC comment
§6.1 on Client authentication* has the following requirement, The Principal MUST identify an authorized accessor. If the assertion is self-issued, the Principal SHOULD be the client_id. which doesn't really make sense for client authentication. The self-issuedness of the assertion should have no bearing on the principal (rather the issuer) and, when used for client authentication, the principal should always represent the client. I believe the bullet should instead say, The Principal SHOULD be the client_id. * http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-6.1 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-assertions WGLC comment II
The third paragraph of §4.1* has, The following section defines the use of assertions as client credentials as an extension of Section 3.2http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-3.2of OAuth 2.0 [ I-D.ietf.oauth-v2http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#ref-I-D.ietf.oauth-v2]. However the Section 3.2 link is to #section-3.2 in the assertions document (which doesn't exist and is the wrong document) rather than to the core OAuth document. I think it should probably reference §2.3 (rather than 3.2) of oauth-v2** and the link should be fixed or removed. * http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.1 ** http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-assertions WGLC comment IV
§4.2* discusses the use of the scope parameter in an authorization grant request. This section should probably reference §3.3 of draft-ietf-oauth-v2** for the formal definition of scope and, subsequently, a fair amount of text can be removed from the assertions draft. * http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2 ** http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3.3 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] double normative? (draft-ietf-oauth-assertions WGLC comment V)
Sections 6.1, 6.2, 6.3 and 6.4 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 are all similar in that they have a paragraph at the top that ends with, The following format and processing rules SHOULD be applied: followed by a bullet list of specific rules. However some of the individual bullets themselves have normative language including several that have a MUST. On rereading the draft today, I found this to be a little confusing. I mean, what does it mean to say that you SHOULD MUST do something? At a minimum, it seems like kind of bad form. I'm thinking that the lead in text before each list should just say something like The following format and processing rules are to be applied: to avoid any potential logical conflict between the normative terms. But depending on how the previous text was interpreted, that could be considered a breaking change? That might be okay though as this is just an abstract specification. Any thoughts? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-assertions WGLC comment VI
The treatment of client_id draft-ietf-oauth-assertions-01 seems a bit inconsistent/problematic. §4.1 4.2 say it's OPTIONAL. §'s 6.1 and 6.2 have, The client_id HTTP parameter SHOULD identify the client to the authorization server while 6.3 and 6.4 have, The client_id HTTP parameter MUST identify the client to the authorization server. Are these intended to be the stronger than the optional in the 4.xs? Or to say that it should/must identify the client, in the case that the parameter is present? I would suggest that all of those except the one in §4.1 be removed and that the 4.1 one changed to say, client_id OPTIONAL. The client identifier as described in Section 2 of OAuth 2.0 [I-D.ietf.oauth-v2]. When present, the client_id MUST (or SHOULD?) identify the client to the authorization server. That would cover the client authentication cases and defer to the core spec for authorization cases (thought it's not 100% clear, I think it says or should say that it's optional in most cases). I'm not sure if that meets the original intent though? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
You're right, resource owner credentials is specifically for username and password. If by RSA you mean a one time password from a hard token, you might be able to kind of shove it into a resource owner credentials flow. But I don't think that was really the intent. If you mean RSA signatures, then it doesn't really work. In general stronger forms of user authentication for direct client to AS communications are allowed for by the extensibility of the grant type mechanism: http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.5but that does require an extension spec or a proprietary implementation. There is work underway to standardize some assertion/token grants with this abstract definition http://tools.ietf.org/html/draft-ietf-oauth-assertionsand these more concrete definitions for SAML and JWT respectively http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer and http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer Neither of those directly address the question of other forms of stronger authentication directly with the AS. However some from of stronger authn could have been used to acquire the SAML or JWT - maybe an X509 token sent to an STS. Admittedly that just kind of pushes the problem around and there's some chicken and egg going on here. On Thu, Apr 19, 2012 at 4:25 PM, Lewis Adam-CAL022 adam.le...@motorolasolutions.com wrote: Hi Brian, ** ** I was also looking at the resource owner credentials flow, but it seems limited to username password … it’s not clear that it would work with stronger authentication methods such as RSA. Thoughts? ** ** adam ** ** *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] *Sent:* Thursday, April 19, 2012 5:08 PM *To:* Lewis Adam-CAL022 *Cc:* Justin Richer; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token ** ** A browser isn't required. The browser based flows are pretty common with OAuth but they are certainly not the only way to get a token. The resource owner credentials and client credentials grant types are both involve only direct communication between the client and the AS. And there are also the SAML and JWT grants that allow a client to get an access token directly from an AS without a browser being involved. On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 adam.le...@motorolasolutions.com wrote: Hi Justin, There is one thing I have not understood about the whole external browser vs. embedded browser guidance … and that is, why is **any** browser needed? Java for example has an HTTP library, and OAuth is RESTful. So why is it necessary to require the web browser at all, whether external or embedded? Why can’t my native client make RESTful API calls to the AS and RS natively? Tx! adam *From:* Justin Richer [mailto:jric...@mitre.org] *Sent:* Friday, April 13, 2012 11:38 AM *To:* Lewis Adam-CAL022 *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options. One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a public client with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like myapp://oauthcallback, and register your app on the device as the handler for myapp. In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to myapp://oauthcallback?code=basdf132. Your app grabs the myapp:// url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token. Some key points: 1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this. 2) Your app is public because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime. 3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out. 4) Another app can try to register myapp:// and intercept your code on the way through, so make sure your codes are all one time use and short lived. None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly
Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
A browser isn't required. The browser based flows are pretty common with OAuth but they are certainly not the only way to get a token. The resource owner credentials and client credentials grant types are both involve only direct communication between the client and the AS. And there are also the SAML and JWT grants that allow a client to get an access token directly from an AS without a browser being involved. On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 adam.le...@motorolasolutions.com wrote: Hi Justin, ** ** There is one thing I have not understood about the whole external browser vs. embedded browser guidance … and that is, why is **any** browser needed? Java for example has an HTTP library, and OAuth is RESTful. So why is it necessary to require the web browser at all, whether external or embedded? Why can’t my native client make RESTful API calls to the AS and RS natively? ** ** Tx! adam ** ** *From:* Justin Richer [mailto:jric...@mitre.org] *Sent:* Friday, April 13, 2012 11:38 AM *To:* Lewis Adam-CAL022 *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token ** ** If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options. One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a public client with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like myapp://oauthcallback, and register your app on the device as the handler for myapp. In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to myapp://oauthcallback?code=basdf132. Your app grabs the myapp:// url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token. Some key points: 1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this. 2) Your app is public because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime. 3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out. 4) Another app can try to register myapp:// and intercept your code on the way through, so make sure your codes are all one time use and short lived. None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly on your platform (both server and client side). -- Justin On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: Hi all, I’ve been talking to some of you off line about this already, but I need some help in terms of implementation. I would like to use OAuth as a means to get either a JWT or SAML token to a client running on a handheld device. This is something that I’m looking to prototype (as part of a larger project) beginning this week. So, it is important to me to understand the divide between what is theoretically possible and what is actually possible. Anybody aware of any implementations out there, either vendor or open source, that I can use for this? Tx! adam ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ** ** ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 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
[OAUTH-WG] typo/missing word in JWT and SAML I-Ds
I was putting together a little summary writeup on some of these drafts yesterday and I noticed a missing a in the abstract of http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03 - it says, This specification defines the use of a JSON Web Token (JWT) Bearer Token as means for requesting... but should probably say This specification defines the use of a JSON Web Token (JWT) Bearer Token as *a* means for requesting... And http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 has nearly the identical omission. The latter draft is in WGLC and I wasn't sure if I should produce a new revision to correct this little editorial item now or wait until after last call? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on Assertion Drafts
Thanks Justin, a couple comments/questions are inline... On Thu, Apr 5, 2012 at 10:53 AM, Justin Richer jric...@mitre.org wrote: http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 Section 7's second portion about a client including multiple credentials types seems buried down here in the Error Responses section for something this fundamental. Yeah, I can see that. Although the restriction on multiple client authentication methods is actually inherited from core OAuth (last sentence in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3) so maybe there shouldn't even normative language about it in this doc? It also conflates discussion of selection of this client authorization type in here, where it ought to be in its own section, closer to the top. I'm not sure I follow you here? As I re-read §7 I think it might make sense to break it into two pieces, one on grants and one on client auth. Maybe a 7.1 and a 7.2 or maybe subsections of §4, like a §4.1.1 for client authentication errors and §4.2.1 for authz/grant errors. But I don't think that was what your comment was about? Was your comment that this text should live somewhere else? Token endpoints can differentiate between assertion based credentials and other client credential types by looking for the presence of the client_assertion and client_assertion_type attributes which will only be present when using assertions for client authentication. I wouldn't disagree with you there, if that was the case. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-saml2-bearer-10 question
It really depends on the situation - what other systems are available to the client and the nature of the trust relationship between the client and the AS. As John said, a client could generate and self sign an assertion. This likely works for well for client authentication via asymmetric keys. WS-Trust/STS is the most typical (in my view anyway) way a client might get an assertion to use for authorization. We've got a few customers doing it that way. I did a little demo a while back using WS-Trust but where the assertion issuer acts as a broker of sorts in the transaction rather than returning the assertion to the client: https://www.pingidentity.com/blogs/pingtalk/index.cfm/2010/11/5/Securing-Mobile-for-Enterprise--SAML-OAuth-WSTrust-in-Action ECP is possible but you are right that lack of support for it makes it unlikely. Various permutations of Web SSO are possible too. The client might be a SAML SP, for example, and get an assertion from an IDP that's suitable for both SSO and use as a grant type. Although, in current practice, I don't think IDP support for issuing such assertions is very good. And there's nothing ruling out some kind of simple proprietary exchange between the client and the assertion issuer. On Thu, Apr 5, 2012 at 7:46 PM, John Bradley ve7...@ve7jtb.com wrote: Adam, It may be a self signed SAML assertion. That is likely the case where someone wanted to use asymmetric keys to authenticate to the Token Endpoint. I could see an STS used in some cases. ECP is a touch unlikely unless someone was super keen. The client could use a Web SSO profile to get a assertion for the user if you are using the Assertion profile for the Authorization endpoint. There is also a JWT token profile for assertions, you knew I couldn't resist a plug:) John B. On 2012-04-05, at 10:35 PM, Lewis Adam-CAL022 wrote: Hi, ** ** Reading draft-ietf-oauth-saml2-bearer-10, it states: ** ** The process by which the client obtains the SAML Assertion, prior to exchanging it with the authorization server or using it for client authentication, is out of scope. ** ** Accepting that it’s out of scope from the draft, what are the realistic alternatives to obtaining the SAML assertion out of band? WS-Trust provides a direct method to request a SAML assertion from a STS, and the SAML ECP profiles seems to allow this behavior, but it doesn’t seem like ECP is very well supported. What other viable means are there from a client to directly request a SAML assertion from an assertion issuer? ** ** Tx! adam ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Google using JTW assertions?
I noticed this post http://googledevelopers.blogspot.se/2012/03/service-accounts-have-arrived.html, via a tweet from a colleague, that mentions sending a JWT to Google’s OAuth 2.0 Authorization Server in exchange for an access token. The post mentions compliance of draft 25 of OAuth v2 but doesn't give much more detail. I'm wondering if any Google folks on this list know if it was implemented to the http://tools.ietf.org/html/draft-ietf-oauth-assertions http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer specs? It would be great to have some feedback one way or the other on the applicability of those documents from a real world deployment. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Assertions (was Agenda Proposal)
Unfortunately I will not be in Paris for the Thrus meeting but I'd love to see the assertion drafts progress. So thanks to Hannes for putting it on the agenda and to Mike for owning that portion of it. There's been some light discussion on this list around the assertion stuff but, as far as I know, there's only been one question raised that might potentially involve changes: http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html Just a nit/clarification that while draft-ietf-oauth-urn-sub-ns is used by draft-ietf-oauth-saml2-bearer, it is intended to have a broader scope and not just limited to assertions. It should be a means of registering urn:ietf:params:oauth:* URNs for any OAuth related specifications or extensions that might need one. On Wed, Mar 14, 2012 at 2:14 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Feedback appreciated! 3. OAuth Assertions (Mike) https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
+1
On Mar 11, 2012 7:08 AM, John Bradley ve7...@ve7jtb.com wrote:
+1
Sent from my iPhone
On 2012-03-10, at 12:49 PM, Mike Jones michael.jo...@microsoft.com
wrote:
I plan to make the change to the example access token value to
mF_9.B5f-4.1JqM before Monday’s submission deadline, per the requests for
b64token syntax clarification. I’m also considering adding an access token
response example, pre the requests in this thread. I would propose adding
the following new text for this in a new Section 4 (before the current
Security Considerations). This is largely parallel to what is done in
Section 5.1 of the MAC spec.
** **
*4. Example Access Token Response*
** **
Typically a bearer token is returned to the client as part of an OAuth 2.0
[I-D.ietf-oauth-v2] access token response. An example of such as response
is:
** **
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
** **
{
access_token:mF_9.B5f-4.1JqM,
token_type:Bearer,
expires_in:3600,
refresh_token:tGzv3JOkF0XG5Qx2TlKWIA
}
** **
Please send either +1s or objections to this text by mid-day Monday.
Unless I receive several +1s, to be conservative at this point, I will not
be including it in Monday’s draft.
** **
-- Mike
** **
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
Of *Paul Madsen
*Sent:* Wednesday, March 07, 2012 1:34 PM
*To:* Brian Campbell
*Cc:* oauth
*Subject:* Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer
** **
+1
On 3/7/12 4:08 PM, Brian Campbell wrote:
Yeah, it is case insensitive. I just went with the upper case B
because that's how it was written in §5.1.1 of
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
Either one would be fine.
** **
I agree that an example response from the token endpoint would be
worthwhile. Something like the following might help tie together with
the Authorization header example (proposed earlier). It could maybe be
worked in near the top of §2?
** **
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
** **
{
access_token:vF_9.5dCf-t4.qbcmT_k1b,
token_type:example,
expires_in:3600,
refresh_token:stGzv3xOdkF0X35Qp2TlKWIA,
}
** **
It'd probably make sense to change the examples in the body §2.2***
and query §2.3 to use the same access token value too.
** **
** **
* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3
** **
** **
On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer jric...@mitre.org
jric...@mitre.org wrote:
Makes sense to me, except that I think the token_type value is typically
lowercase bearer, though it's defined to be case insensitive in
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value
of
this field for the Bearer token type ever got defined anywhere. Section
7.1
references the bearer spec as defining the value of the token_type
parameter, and passes its example as if by reference. Would be worthwhile
giving an example of a token endpoint response, such as what's found in
OAuth-v2-23 section 5.1.
** **
-- Justin
** **
** **
On 03/07/2012 12:16 PM, Brian Campbell wrote:
** **
I'd like to propose the following changes and additions, derived
largely from Bill and James suggestions, to
draft-ietf-oauth-v2-bearer-17. These changes have no normative impact
and only aim to add additional clarity and explanation the workings
and implications of the current spec. I'm definitely open to changes
or improvements in the wording here (not my strong suit by any means)
but I think it's important that these general ideas be conveyed in the
draft.
** **
** **
== Insert the following text at the beginning of §2:
** **
To make a protected resource request, the client must be in possession
of a valid bearer token. Typically a bearer token is returned to the
client as part of an access token response as defined in OAuth 2.0
[I-D.ietf-oauth-v2]. When the token_type parameter of the access
token response is Bearer, the string value of the access_token
parameter becomes
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
I'd like to propose the following changes and additions, derived largely from Bill and James suggestions, to draft-ietf-oauth-v2-bearer-17. These changes have no normative impact and only aim to add additional clarity and explanation the workings and implications of the current spec. I'm definitely open to changes or improvements in the wording here (not my strong suit by any means) but I think it's important that these general ideas be conveyed in the draft. == Insert the following text at the beginning of §2: To make a protected resource request, the client must be in possession of a valid bearer token. Typically a bearer token is returned to the client as part of an access token response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. When the token_type parameter of the access token response is Bearer, the string value of the access_token parameter becomes the bearer access token used to make protected resource requests. == Change the value of the token in the Authorization header example to this: Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b == Insert the following text before the last paragraph of §2.1: Note that the name b64token does not imply base64 encoding but rather is the name for an ABNF syntax definition from HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]. Because of its use, the access_token string value from an access token response MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Thanks, Brian On Tue, Mar 6, 2012 at 11:45 AM, William Mills wmi...@yahoo-inc.com wrote: Yeah, something as simple as, Note that the name 'b64token' does not imply base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would do it. -bill From: Brian Campbell bcampb...@pingidentity.com To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Sent: Tuesday, March 6, 2012 8:23 AM Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones michael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token response is the bearer token. The access_token string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the Bearer OAuth access token type is defined. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Yes. * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Yeah, it is case insensitive. I just went with the upper case B
because that's how it was written in §5.1.1 of
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
Either one would be fine.
I agree that an example response from the token endpoint would be
worthwhile. Something like the following might help tie together with
the Authorization header example (proposed earlier). It could maybe be
worked in near the top of §2?
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
access_token:vF_9.5dCf-t4.qbcmT_k1b,
token_type:example,
expires_in:3600,
refresh_token:stGzv3xOdkF0X35Qp2TlKWIA,
}
It'd probably make sense to change the examples in the body §2.2***
and query §2.3 to use the same access token value too.
* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3
On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer jric...@mitre.org wrote:
Makes sense to me, except that I think the token_type value is typically
lowercase bearer, though it's defined to be case insensitive in
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of
this field for the Bearer token type ever got defined anywhere. Section 7.1
references the bearer spec as defining the value of the token_type
parameter, and passes its example as if by reference. Would be worthwhile
giving an example of a token endpoint response, such as what's found in
OAuth-v2-23 section 5.1.
-- Justin
On 03/07/2012 12:16 PM, Brian Campbell wrote:
I'd like to propose the following changes and additions, derived
largely from Bill and James suggestions, to
draft-ietf-oauth-v2-bearer-17. These changes have no normative impact
and only aim to add additional clarity and explanation the workings
and implications of the current spec. I'm definitely open to changes
or improvements in the wording here (not my strong suit by any means)
but I think it's important that these general ideas be conveyed in the
draft.
== Insert the following text at the beginning of §2:
To make a protected resource request, the client must be in possession
of a valid bearer token. Typically a bearer token is returned to the
client as part of an access token response as defined in OAuth 2.0
[I-D.ietf-oauth-v2]. When the token_type parameter of the access
token response is Bearer, the string value of the access_token
parameter becomes the bearer access token used to make protected
resource requests.
== Change the value of the token in the Authorization header example to
this:
Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b
== Insert the following text before the last paragraph of §2.1:
Note that the name b64token does not imply base64 encoding but rather
is the name for an ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. Because of its use, the access_token
string value from an access token response MUST match the b64token
ABNF so it can be used with the Bearer HTTP scheme.
Thanks,
Brian
On Tue, Mar 6, 2012 at 11:45 AM, William Millswmi...@yahoo-inc.com
wrote:
Yeah, something as simple as, Note that the name 'b64token' does not
imply
base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would
do
it.
-bill
From: Brian Campbellbcampb...@pingidentity.com
To: Mike Jonesmichael.jo...@microsoft.com
Cc: oauthoauth@ietf.org
Sent: Tuesday, March 6, 2012 8:23 AM
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer
Thanks Mike, I think changing the example would be helpful.
However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.
I can propose some specific text (building on James') if others in the WG
agree?
On Mon, Mar 5, 2012 at 5:32 PM, Mike Jonesmichael.jo...@microsoft.com
wrote:
I'm fine with changing the example to make it clearer that b64token
allows
a wider range of characters than just those legal for base64 and
base64url
encodings of data values.
I'll add it to my to-do list for any additional edits for the Bearer
spec.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of
Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones michael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token response is the bearer token. The access_token string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the Bearer OAuth access token type is defined. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Yes. * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 -- 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
[OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Thanks, Brian * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: [OAuth2.0][SAML2.0] 2.2. Using SAML Assertions for Client Authentication Problem ?
I wanted to get the below question and answer to the right place. -- Forwarded message -- From: Brian Campbell brian.d.campb...@gmail.com Date: Wed, Feb 1, 2012 at 9:01 AM Subject: Re: [OAuth2.0][SAML2.0] 2.2. Using SAML Assertions for Client Authentication Problem ? To: Shiu Fun Poon shiufunp...@gmail.com Cc: cmortim...@salesforce.com Hi Shiu, Section 2.2 is about client authentication and the parameter names are correct for that context (the names are defined in http://tools.ietf.org/html/draft-ietf-oauth-assertions and this profile defines the values for use with SAML). The example in Section 4 that uses assertion and grant_type is about authorization and not client authentication. And it is consistent with section 2.1 Thanks, B On Tue, Jan 31, 2012 at 10:29 PM, Shiu Fun Poon shiufunp...@gmail.comwrote: Hi.. Reading the latest spec.. are there typos in the following section ? 2.2. Using SAML Assertions for Client Authentication he value of client_assertion_type parameter MUST ?? Should this be grant_type The value of the client_assertion parameter ?? Is this assertion (which is what is shown in the example). Thanks. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SAML Bearer Spec 09 - Refresh Clarification
Sorry, I had a section reference and link wrong in the previous message. The question/suggestion about moving some text into the OAuth 2.0 Assertion Profile should have referenced section 4.2 and linked to here: http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2 That mistake also gives me an excuse to raise this to the WG again. I suggest that whatever text we settle on be moved to general assertion profile. I'm not sure I know what that text should be. On Fri, Dec 16, 2011 at 3:58 PM, Brian Campbell bcampb...@pingidentity.comwrote: Hey Phil, Your understanding is pretty much inline with how I understand it. That text actually originates from earlier versions of the core spec (I think -09 [1] was the last sighting). And I carried it over when the grant_type got generalized and the assertion pieces moved into the SAML/OAuth draft. The main idea was that the extension grants (or at least assertions) relied on some existing trust framework and that issuing a refresh token would effectually undermine that by giving the client a new way of getting access outside the established framework of trust. So, for example, with an RT a fired employee might still be able to access resources at a SaaS provider. That was the thinking anyway but I don't disagree that the wording in the draft could make that more clear and/or be a less restrictive. Regarding the text you've proposed, I'm not sure I know exactly what lifetime of the authorization grant means or how the AS would know. And I think it might be too ambiguous to have as normative language. Can you give a workable definition? Or was it intentionally left kind of vague? I'll should also note that that exact same text is in section 3.1 of the JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 [2] draft. Whatever we decide, I can't think of any reason it would't apply to both drafts. And that suggests that it should be moved up into the OAuth 2.0 Assertion Profile - perhaps into section 4.1.3 [3]? Thanks, Brian P.S. My apologies for the extremely slow response - this one just slipped though the cracks for a while - I have no other excuse. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 [2] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03#section-3.1 [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.3 On Fri, Nov 4, 2011 at 2:40 PM, Phil Hunt phil.h...@oracle.com wrote: Section 4.5 of the OAuth Core spec provides that extension spec MAY issue refresh tokens. Yet, section 3.1 of the OAuth2 SAML Bearer specification currently says SHOULD NOT (from draft 09): Authorization servers SHOULD issue access tokens with a limited lifetime and require clients to refresh them by requesting a new access token using the same assertion, if it is still valid, or with a new assertion. The authorization server SHOULD NOT issue a refresh token. There has been some confusion as to why authorization servers SHOULD NOT issue refresh tokens. Apparently this wording was put in place because a SAML Bearer authorization might have a shorter life than typical refresh token lifetime. Hence there was a concern that an authorization server would inadvertently issue a long-lasting refresh token that outlives the original SAML Bearer authorization. In order to make this concern clear I propose the following text that makes clear the concern and makes refresh tokens more permissive: Authorization servers SHOULD issue access tokens with a limited lifetime and require clients to refresh them by requesting a new access token using the same assertion, if it is still valid, or with a new assertion. The authorization server SHOULD NOT issue a refresh token that has an expiry longer than the lifetime of the authorization grant. I'm not aware of any other concerns regarding refresh tokens being issued in conjunction with SAML Bearer assertions? Are there any concerns that suggest we should keep the wording as generally SHOULD NOT? Phil @independentid www.independentid.com phil.h...@oracle.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-00.txt
Done. See draft -01 at http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-01 Sorry it took so long to get that little change done. Thanks for the feedback, Peter. On Wed, Nov 9, 2011 at 5:34 PM, Peter Saint-Andre stpe...@stpeter.imwrote: On 8/30/11 1:55 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : An IETF URN Sub-Namespace for OAuth Author(s) : Hannes Tschofenig Filename: draft-ietf-oauth-urn-sub-ns-**00.txt Pages : 5 Date: 2011-08-30 This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. Seems like a good idea. The security considerations point to RFC 3553, but that just points to RFC 2141, so you might as well point to the latter spec. Peter -- Peter Saint-Andre https://stpeter.im/ __**_ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SAML Bearer Spec 09 - Refresh Clarification
Hey Phil, Your understanding is pretty much inline with how I understand it. That text actually originates from earlier versions of the core spec (I think -09 [1] was the last sighting). And I carried it over when the grant_type got generalized and the assertion pieces moved into the SAML/OAuth draft. The main idea was that the extension grants (or at least assertions) relied on some existing trust framework and that issuing a refresh token would effectually undermine that by giving the client a new way of getting access outside the established framework of trust. So, for example, with an RT a fired employee might still be able to access resources at a SaaS provider. That was the thinking anyway but I don't disagree that the wording in the draft could make that more clear and/or be a less restrictive. Regarding the text you've proposed, I'm not sure I know exactly what lifetime of the authorization grant means or how the AS would know. And I think it might be too ambiguous to have as normative language. Can you give a workable definition? Or was it intentionally left kind of vague? I'll should also note that that exact same text is in section 3.1 of the JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 [2] draft. Whatever we decide, I can't think of any reason it would't apply to both drafts. And that suggests that it should be moved up into the OAuth 2.0 Assertion Profile - perhaps into section 4.1.3 [3]? Thanks, Brian P.S. My apologies for the extremely slow response - this one just slipped though the cracks for a while - I have no other excuse. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 [2] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03#section-3.1 [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.3 On Fri, Nov 4, 2011 at 2:40 PM, Phil Hunt phil.h...@oracle.com wrote: Section 4.5 of the OAuth Core spec provides that extension spec MAY issue refresh tokens. Yet, section 3.1 of the OAuth2 SAML Bearer specification currently says SHOULD NOT (from draft 09): Authorization servers SHOULD issue access tokens with a limited lifetime and require clients to refresh them by requesting a new access token using the same assertion, if it is still valid, or with a new assertion. The authorization server SHOULD NOT issue a refresh token. There has been some confusion as to why authorization servers SHOULD NOT issue refresh tokens. Apparently this wording was put in place because a SAML Bearer authorization might have a shorter life than typical refresh token lifetime. Hence there was a concern that an authorization server would inadvertently issue a long-lasting refresh token that outlives the original SAML Bearer authorization. In order to make this concern clear I propose the following text that makes clear the concern and makes refresh tokens more permissive: Authorization servers SHOULD issue access tokens with a limited lifetime and require clients to refresh them by requesting a new access token using the same assertion, if it is still valid, or with a new assertion. The authorization server SHOULD NOT issue a refresh token that has an expiry longer than the lifetime of the authorization grant. I'm not aware of any other concerns regarding refresh tokens being issued in conjunction with SAML Bearer assertions? Are there any concerns that suggest we should keep the wording as generally SHOULD NOT? Phil @independentid www.independentid.com phil.h...@oracle.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 2 Leg with OAuth 2.0
Or using the SAML or JWT grants to get an access token, then using the protocol as usual. On Tue, Nov 29, 2011 at 1:06 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: This functionality can be implemented in two main ways: 1. Using the client credentials flow to get an access token, then using the protocol as usual 2. Just using the Bearer (over SSL) or MAC token schemes without the rest of OAuth EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Hawkins Sent: Tuesday, November 29, 2011 11:49 AM To: oauth@ietf.org Subject: [OAUTH-WG] 2 Leg with OAuth 2.0 I'm having trouble finding information on how to do 2leg authentication with OAuth 2.0. Does it even support it? Thanks Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-saml2-bearer-09.txt
I posted a new draft that addresses a potential ambiguity raised by an engineer I work with who is currently implementing against the draft. draft -09 can be found at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-09 and here's the relevant snippet from Appendix B. Document History: draft-ietf-oauth-saml2-bearer-09 o Attempt to address an ambiguity around validation requirements when the Conditions element contain a NotOnOrAfter and SubjectConfirmation/SubjectConfirmationData does too. Basically it needs to have at least one bearer SubjectConfirmation element but that element can omit SubjectConfirmationData, if Conditions has an expiry on it. Otherwise, a valid SubjectConfirmation must have a SubjectConfirmationData with Recipient and NotOnOrAfter. And any SubjectConfirmationData that has those elements needs to have them checked. o clarified that AudienceRestriction is under Conditions (even though it's implied by schema) o fix a typo -- Forwarded message -- From: internet-dra...@ietf.org Date: Fri, Oct 28, 2011 at 11:22 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-09.txt To: i-d-annou...@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-09.txt Pages : 16 Date : 2011-10-28 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-09.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Status and next steps on Assertions
A few of us had a chance to meet face to face this morning at IIW 13 in Mountain View and talked a bit about the assertions document. I wanted to try and (very quickly) summarize that and also talk about the some next steps for these documents. This is partly a summary and partly a reminder of things to be done. The OAuth 2.0 Assertion Profile http://tools.ietf.org/html/draft-ietf-oauth-assertions-00 Hannes and Barry expressed concern about some of the wording (and possibly the SAML one as well?) saying that it could potentially be misleading or confusing regarding the actual security properties implied or provided by the profile. Hannes was going to take a crack at proposing some new text. This draft is due for an update and there have been some comments on it over the last few months. I found http://www.ietf.org/mail-archive/web/oauth/current/msg07186.html which are some general comments from Yaron and http://www.ietf.org/mail-archive/web/oauth/current/msg07173.html which is from me about the need to do parameter registration in this doc. I thought there were some additional comments but I can't seem to find them. Personally, given the treatment of client_id in draft-ietf-oauth-v2-22, I think that this draft needs to rework its handling of client_id. It should probably just be omitted completely from section 4.2. Using Assertions as Authorization Grants and made optional or even forbidden in section 4.1. Using Assertions for Client Authentication An IETF URN Sub-Namespace for OAuth http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-00 I think this short document is ready to go on to whatever is next. SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-08 I believe this document is also ready to go. Although it depends on the previous two documents so they should probably progress together as a group. The only comment I'm aware of on it came from a cross posting at the OASIS SSTC and while I acknowledge what was said, I don't believe it can be addressed. I can provide more detail, if anyone is interested. Hannes said he thought there might be some editorial issues with it or perhaps it contained incorrect URI(s). He wasn't sure if he was working against the latest draft, however, so is planning on double checking and providing comments if appropriate. JSON Web Token (JWT) Bearer Profile for OAuth 2.0 http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 Mike is going to update this draft to be an instance of draft-ietf-oauth-assertions-00 similar to what draft-ietf-oauth-saml2-bearer-08 does. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed resolution for issue 26
+1 to I think James made it pretty clear that we have a problem and
that we have to solve it.
On Wed, Sep 28, 2011 at 10:36 AM, Marius Scurtescu
mscurte...@google.com wrote:
On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba barryle...@computer.org
wrote:
I'd like to see more participation in this thread, besides just from
Mike and James. What do others think?
I think James made it pretty clear that we have a problem and that we have
to solve it.
One solution would be for the core spec to limit the characters that can be
used in a scope, such that scopes are HTTP header safe. I think this would
be pretty limiting and fragile.
Another solution would be for the bearer spec to specify what escaping
should be used. RFC 5987 seems like the only good choice.
Marius
Barry, as chair
On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones michael.jo...@microsoft.com
wrote:
While you take the viewpoint that the bearer spec is restricting scope
values, in fact, the spec intentionally allows all characters that can
be
safely communicated in an HTTP response header parameter to be
used. About whether those characters employ an encoding
methodology to sometimes represent other characters or abstractions,
I believe that Barry's proposed wording hits the nail on the head:
Interpretation of scope strings requires semantic agreement on the
meaning of the scope strings between the parties participating the
OAuth flow. Should an encoding be used for scope strings in a
particular deployment context, participants have to have agreed
upon that encoding, just as they agree on other OAuth configuration
parameters.
Best wishes,
-- Mike
On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
While you take the viewpoint that the bearer spec is restricting scope
values, in fact,
the spec intentionally allows all characters that can be safely
communicated in an HTTP
response header parameter to be used.
But all characters that can be safely communicated in an HTTP response
header parameter is only a subset of the characters that OAuth Core
allows in a scope value (any Unicode string excluding space). I don't
understand how this isn't the Bearer spec restricting scope values.
P.S. You recognize here that non-ASCII chars cannot be safely
communicated in an HTTP response header parameter. This is why
Julian was concerned about the spec saying the error_description holds
raw UTF-8.
[Actually the ABNF for error_description restricts it to 93 ASCII chars
so
when the text says it is UTF-8 encoded it is raising the potential
problem
of arbitrary UTF-8 in HTTP headers unnecessarily.]
--
James Manger
On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
I'll have another go trying to explain the problem I see with the scope
parameter in the Bearer spec.
Consider a French social network that decides to offer an API using
OAuth2.
It chooses 3 scope values for parts of the API related to family,
friends, and
business colleagues:
* famille
* ami
* collègues
Let's focus on the last scope.
The site describes the scope and its semantics in HTML developer docs.
That works.
dtcoll#xE8;gues/dtdd.../dd
Client apps construct authorization URIs to which users are sent.
That works.
https://example.fr/authz?scope=coll%C3%A8gues...
The authorization server issues credentials in a JSON token response.
That works.
{ access_token:SlAV32hkKG, scope:coll\u00E8gues, ...}
The authorization server also supports implicit grants. That works.
Location: https://app.client.org/callback#scope=coll%C3%A8gues...
Client apps request protected resources (without needing to mention
scope).
That works.
Authorization: Bearer vF9dft4qmT
A protected resource server responds with a 401 error when a bearer
token
is wrong. They don't know what to put in the HTTP response header scope
parameter: collègues does not fit.
One server knows HTTP headers have historically used ISO-8859-1.
WWW-Authenticate: Bearer scope=collE8gues,
error_description=opps...
Another server sees that error_description is specified as UTF-8 so uses
that.
WWW-Authenticate: Bearer scope=collC3A8gues,
error_description=opps...
A third server reasons that the value will be copied to an authz URI so
uses
URI-escaping.
WWW-Authenticate: Bearer scope=coll%C3%A8gues,
error_description=opps...
A fourth server thinks JSON-escaping looks most like HTTP's
quoted-string
quoting (both use '\').
WWW-Authenticate: Bearer scope=coll\u00E8gues,
error_description=opps...
A fifth uses RFC 5987 Character Set and Language Encoding for HTTP
Header
Field Parameters:
WWW-Authenticate: Bearer scope*=UTF-8''coll%C3%A8gues,
error_description=opps...
It is a total
[OAUTH-WG] Extensions example update (was Draft -21 next steps)
Although this isn't related to changes made since -20, it should probably still be done (unless it's something for the final RFC editors?) and shouldn't be much of a change. The example in section 4.5 [1] uses the old grant type URI for the SAML grant type (http://oauth.net/grant_type/saml/2.0/bearer) and it should probably be updated to use the new and hopefully final and stable one (urn:ietf:params:oauth:grant-type:saml2-bearer). Here's the example from the latest SAML draft [2]: POST /token.oauth2 HTTP/1.1 Host: authz.example.net Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Also the source xml, if that's useful: artwork ![CDATA[ POST /token.oauth2 HTTP/1.1 Host: authz.example.net Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-]] /artwork Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-08#section-4 On Sun, Sep 4, 2011 at 5:49 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I’d like to ask the chairs to declare a 2 weeks review period limited to changes made since -20 after which we will either declare -21 as the final WG draft or publish a quick -22 with all changes agreed prior on the list and no additional WG review period. Of course, the chairs can change all these rules as they see fit. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: Invalid Credentials Error Handling
The error should be invalid_grant as it is the grant (the resource
owner's username and password) that is invalid.
On Tue, Sep 13, 2011 at 10:07 AM, Colm Divilly colm.divi...@oracle.com wrote:
Apologies if this has been covered before, a cursory search of the archives
and issue tracker didn't turn up anything.
What is the expected error response when performing a Resource Owner
Password Credentials flow, if the resource owner provides incorrect
credentials?
From reading the spec it looks like the expectation is that a response like
the following should be generated:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
error:invalid_request
}
Which is not terribly helpful for a user-agent trying to determine that it
is the user supplied credentials at fault (and therefore be able to
re-prompt the user for credentials). Perhaps something like the following
would be more useful:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
error:invalid_resource_owner_credentials
}
A bit verbose perhaps, any alternative suggestions?
Regards,
Colm Divilly
___
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] Mail regarding draft-ietf-oauth-saml2-bearer
Hi Michael, I apologize for being so slow in responding to this. I did not receive the first message and haven't had a chance to respond to this direct email as I've been very busy trying to get a product release out the door. I attempt to answer the questions inline below. I'm also cc'ing the OAUTH WG mailing list as these are questions that others might have too. Note there are also questions about draft-ietf-oauth-assertions-00 too. Thanks for the review and feedback. Hopefully I can address your questions. Brian On Mon, Aug 15, 2011 at 5:50 AM, Engler, Michael michael.eng...@sap.com wrote: Hi Brian, possibly the previous mail was lost somewhere in the IETF mailinglists … thus I send here again directly. I apologize if you now received it twice … J Greetings, Michael _ From: Engler, Michael Sent: Mittwoch, 10. August 2011 18:11 To: 'draft-ietf-oauth-saml2-bea...@tools.ietf.org' Cc: Doersam, Joachim Subject: Mail regarding draft-ietf-oauth-saml2-bearer Hi Brian, I are currently reading your latest draft on SAML bearer assertion usage in OAuth 2. Some parts are currently unclear, and it would be great if you could bring light into the dark J … In the document I read the following: “If the Assertion was issued with the intention that the presenter act autonomously on behalf of the subject, an AuthnStatement SHOULD NOT be included. The presenter SHOULD be identified in the NamseID or similar element, the SubjectConfirmation element, or by other available means like [OASIS.saml-deleg-cs].” What does it actually mean if the presenter (= OAuth client) acts autonomously but still on behalf of the subject? Isn’t this a contradiction? Perhaps 'autonomously' isn't the best word there and I'm open to suggestions on an alternative. What I'm trying to do is differentiate between two general cases: 1) the case where the user/resource owner is present to the client in some way and the client has authenticated the resource owner or is sufficiently confident in the authentication event and 2) the case where the client is doing something on behalf of a resource owner but the resource owner isn't present to the client and hasn't directly authenticated with the client. An example of the former case might be where the client is some web application that the resource owner has logged onto and is using at the time of this transaction. The later case might be where the client is some cron job or something that runs nightly and does something on the user or users behalf but without them being around for the transaction. Can you elaborate more on this point why the authentication statement should be left out here? Related to what I said above, there are cases where the resource owner hasn't authenticated with the client (or some STS) and so it seems like it makes sense to say that no claim should be made in the assertion about any type of authentication. In that case, it's really just a claim about some identity about whom this access token is being requested. Should the SAML subject reference the resource owner, or the OAuth client in that case? My intent is that the subject (or the subject and some of the attributes) should reference the resource owner while the delegation to the client (though it's kind of implied) can be expressed through other semantics in the assertion (that's what the second sentence from the piece of the spec you quoted is intended to cover). In section 3.1 you write that “If present, the authorization server MUST also validate the client credentials.“ … What is the syntax for adding the client credentials to the assertion request in case of the SAML bearer token? Do you refer to the separate assertion covering the client as SAML subject … or are there yet another type of client credentials to take into account? The means of client authentication is totally independent from the grant type being presented (true for SAML grant type but also in general). That statement is just intended to ensure that client credentials aren't ignored, if they are there. I would assume that the client id needs to be transferred as part of the access token request. In draft-ietf-oauth-assertions-00 you write the following: The following non-normative example demonstrates an assertion being used as an authorization grant. (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3 grant_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 Why do you assume it is sufficient that the client_id is not contained within the assertion but is “solely” added to the request? In our discussions so far, we assumed that the client id could be transferred as an attribute statement within the SAML assertion. This would prevent tampering
Re: [OAUTH-WG] Comments on Assertions draft 00 by Yaron Goland
Couple comments on the comments inline: On Wed, Aug 10, 2011 at 3:39 PM, Mike Jones michael.jo...@microsoft.com wrote: 4.1. Using Assertions for Client Authentication: Comment on “client_id”: “It seems like a bad idea to have the client_id outside of the assertion. It’s either redundant or insecure.” I tend to agree with this. Now that treatment of client_id seems to have stabilized in the core spec, this draft is probable due for some reconciliatory changes around the parameter. 7. Error Responses: Comment on “Audience validation failed”: “Isn’t returning this kind of information just helping an attacker to hone their attack by trying various values and seeing what errors they get? I’m not sure how serious this threat is though. But I get nervous any time we leak data about security validation failures.” Trying to walk the line between security and having useful feedback available for troubleshooting during the early stages of deployments. Given that there's a signature over the assertion, providing details about other semantic validation issues doesn't seem like an issue to me. But I know that such information disclosure is usually considered a no no in security related contexts. Anyway, the error_description parameter is optional so individual implementation/deployments can make their own decisions about what, if anything, to put there and/or when to put info there. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-saml2-bearer-06.txt
This -06 draft at http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-06 contains only a few fixes to typos identified by my colleague Peter Motykowski. -- Forwarded message -- From: internet-dra...@ietf.org Date: Fri, Aug 19, 2011 at 7:56 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-06.txt To: i-d-annou...@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-06.txt Pages : 15 Date : 2011-08-19 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-06.txt ___ 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] treatment of client_id for authentication and identification
FWIW, I was okay with the text EHL had originally proposed for 21. client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-05.txt
This 'nice' version of this is at http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 The draft has been reworked significantly to become a profile of http://tools.ietf.org/html/draft-ietf-oauth-assertions-00 and cover both assertions as access grants as well as assertions as client authentication. The grant_type URI value no longer uses oauth.net and is urn:ietf:params:oauth:grant-type:saml2-bearer which is registered/requested per http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns and a new URI of urn:ietf:params:oauth:client-assertion-type:saml2-bearer is introduced for client_assertion_type. Lastly the processing rules on the assertion have been relaxed somewhat to allow for SubjectConfirmationData element(s) to be optional when the Conditions element has a NotOnOrAfter attribute. Thanks, Brian On Wed, Aug 3, 2011 at 3:16 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-05.txt Pages : 15 Date : 2011-08-03 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Parameter Registration Requests in draft-ietf-oauth-assertions
One of the changes I made in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 was to drop the parameter registration request for the assertion parameter because the parameter is now defined in http://tools.ietf.org/html/draft-ietf-oauth-assertions however that document doesn't currently have the registration request in its IANA Considerations section. It probably needs to have that as well as requests for client_assertion and client_assertion_type. To bootstrap that bit of work, I've included the XML source for the assertion parameter request from a previous version of the SAML document: section title='IANA Considerations' section title='Parameter Registration Request' t The following is the parameter registration request, as defined in The OAuth Parameters Registry of xref target=I-D.ietf.oauth-v2The OAuth 2.0 Authorization Protocol/xref, for the spanx style='verb'assertion/spanx parameter: list style='symbols' tParameter name: assertion/t tParameter usage location: token request /t tChange controller: IETF/t tSpecification document(s): [[this document]]/t /list /t /section /section ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
That was more or less what I was trying to say as well. There are times when client identification is needed at the token endpoint and it's not clear if or how, short of actual authentication, the current spec allows for it. On Wed, Jul 27, 2011 at 11:38 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] treatment of client_id for authentication and identification
I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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] treatment of client_id for authentication and identification
I'm asking from both an implementation perspective as well as the spec perspective. On the spec side, draft-ietf-oauth-assertions will deal with client_id and while it's currently required I'd guess it will become optional or even forbidden. On the implementation side, let me make sure I understand. Clients without a secret must present client_id on token endpoint requests and must use only that method of identifying themselves? HTTP Basic and other means of client authentication are reserved for clients that actually have some secret to authenticate with? On Mon, Jul 25, 2011 at 10:50 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: It shouldn't. You are still allowed to reuse client_id outside the specific password credentials use case. Just make sure the way the parameter is defined in v2 is consistent. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 25, 2011 9:28 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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] Extra Authorization: Basic lines in examples
I believe those examples are okay. The content in the post body is the grant while the HTTP Basic Authorization header is the client authentication. They are two different things. On Mon, Jul 25, 2011 at 10:27 PM, Mike Jones michael.jo...@microsoft.com wrote: In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=passwordusername=johndoepassword=A3ddj3w I believe that the “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- Mike ___ 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] SAML Assertion Draft Items [Item 1: client auth]
Not before the submission deadline tomorrow. Probably sometime before submissions reopen. On Sat, Jul 9, 2011 at 9:04 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Sounds reasonable. Can you provide a schedule outline? EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Saturday, July 09, 2011 5:53 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth] Thanks for the response, Eran. I'm breaking this thread up into the distinct issues. Reply inline below to the first item about client auth. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: However, the SAML draft does not currently cover SAML for client authentication and profiling draft-ietf-oauth-assertions would suggest that it should. Is there any general consensus as to if SAML should be profiled as a client authentication method? It is certainly feasible but might require restructuring and retitling the draft. Are there use cases pending such functionality today? It would be a shame to delay an otherwise useful draft when the functionality can be added later. I don't have any such use cases in the near future. Perhaps others can speak up? I personally see assertion based grants as being more important and more immediately useful. That was one of the reasons I was looking to keep assertion grants and client assertion authentication separate. That said, Chuck has done a nice job with his general treatment of them together in draft-ietf-oauth-assertions and the logical thing to do, in terms of how the various documents play together, would be to have draft-ietf-oauth-saml2- bearer cover client auth now too. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth]
Thanks for the response, Eran. I'm breaking this thread up into the distinct issues. Reply inline below to the first item about client auth. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: However, the SAML draft does not currently cover SAML for client authentication and profiling draft-ietf-oauth-assertions would suggest that it should. Is there any general consensus as to if SAML should be profiled as a client authentication method? It is certainly feasible but might require restructuring and retitling the draft. Are there use cases pending such functionality today? It would be a shame to delay an otherwise useful draft when the functionality can be added later. I don't have any such use cases in the near future. Perhaps others can speak up? I personally see assertion based grants as being more important and more immediately useful. That was one of the reasons I was looking to keep assertion grants and client assertion authentication separate. That said, Chuck has done a nice job with his general treatment of them together in draft-ietf-oauth-assertions and the logical thing to do, in terms of how the various documents play together, would be to have draft-ietf-oauth-saml2-bearer cover client auth now too. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]
Discussion on the other item, the grant_type URI, inline below. This whole thing seems like it shouldn't be an issue at all as there's no functionality involved. But I've been hung up on it for a while and the spec needs some URI. I could *really* use the advice of the AD and/or Chairs on this. Or anyone with more experience with defining and using URIs/URNs. Thanks. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Item 2: URI(s) The value for grant_type is currently defined as http://oauth.net/grant_type/saml/2.0/bearer but there have been some questions raised about the stability and appropriateness of the URL. I'm not a fan. I really did read RFCs 2648 3553, as was suggested at the last F2F meeting, but it's not clear to me how to register an IETF URI and/or if those RFCs are fully appropriate for this. If someone could explain it to me in terms my preschooler could understand, maybe I could jump though the proper hoops to get the URI to be something like urn:ietf:something:something. Asking on the URN list usually helps. I can try that. I'm thinking it'd be something like urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based on seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registration done for that? Or did it just start getting used? Is doing that okay? Otherwise, I can continue to use http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft should also cover client authentication, also define http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version could then follow a similar pattern. Or perhaps we could use the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer subject confirmation method. It seems like that might be close enough to work out without violating anything serious. And it could be used for both grant_type and client_assertion_type, which is nice. Don't use an OASIS URN. That's asking for trouble. Is it really? Because it's conceptually inappropriate? Or because of some supposed (or real) rift between standards bodies? I mean, this whole draft is about profiling SAML assertions (an OASIS spec) for use with OAuth (soon an IETF spec). Would using a URN too be so terrible? You'd previously suggested (or asked why I didn't use) urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the OASIS SAML assertion schema. Would that somehow be different? That is still an option too, I think. I hadn't used it because I wanted to differentiate the means of confirming/validating the assertion - as a bearer token - while leavening room for holder of key or other methods in the future. But using that NS wouldn't necessary preclude it. I was also looking for an identifier that would enable easy web searching and urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do that. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] URI for OAuth SAML assertion grant type
Thank you for taking the initiate to post this, Eran. And thank you, Hannes, for the detailed and actionable reply. If Eran is willing/able to do #1 #2, I'd be more than happy to do #3. On Sat, Jul 9, 2011 at 10:40 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Eran, http://oauth.net/grant_type/saml/2.0/bearer is definitely not a good idea since a lookup would not return anything useful (most likely it will just fail). Whenever there is something that can be looked up, it will be looked up . I would create an IETF URN Sub-namespace, as documented in RFC 3553. An example of such a sub-namespace is xml and described in RFC 3688. So, one could define a new 'oauth' sub-namespace. This would then look like urn:ietf:params:oauth. Then, OAuth relevant parameters would be established underneath it. To get this done three things are needed: 1) Text that requests the oauth sub-namespace text This text has to go into draft-ietf-oauth-v2. 2) Text that defines how values are added to this new registry This text has to go into draft-ietf-oauth-v2. 3) Text that registers already defined values. This text would go into draft-ietf-oauth-saml2-bearer following the template created with (2). Regarding (1), example text could look like: - IETF URN Sub-namespace Registration urn:ietf:params:oauth Per [RFC3553], IANA is requested to establish the following registry. New entries to the registry are Specification Required. Registry name: urn:ietf:params:oauth Specification: Section X of this document contains the registry specification. Repository: To be assigned according to the guidelines found above. Index value: The class name - Regarding (2), example text could look like: - Section X: Registration Template for Sub-Namspace Registration of urn:ietf:params:oauth If the registrant wishes to have a URI assigned, then a URN of the form urn:ietf:params:oauth:class:id will be assigned where class is the category of the parameters being registered. id is a unique id generated by the IANA based on any means the IANA deems necessary to maintain uniqueness and persistence. NOTE: in order for a URN of this type to be assigned, the item being registered MUST be documented in a RFC. The RFC 3553 [RFC3553] URN registration template is found in the IANA consideration section of this document. The registration procedure for new entries to the requires a request in the form of the following template: URN: The token URI that identifies the registerd component. If the registrant is requesting that the IANA assign a URI then this field should be specified as please assign. Common Name: The name by which the functionality being registered is generally referred. Registrant Contact: The individual/organization that is the registration contact for the component being registered. Ideally, this will be the name and pertinent physical and network contact information. In the case of IETF developed standards, the Registrant will be the IESG. Description: Information about the registered functionality. - Regarding (3), example text could look like: - Sub-Namspace Registration of urn:ietf:params:oauth:grant-type:saml2-bearer This is a request to IANA to please register the value grant-type:saml2-bearer in the registry urn:ietf:params:oauth established in [draft-ietf-oauth-v2]. URN: urn:ietf:params:oauth:grant-type:saml2-bearer Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 Registrant Contact: IESG Description: [[this document]] - Other grant types would then go in urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key Other OAuth related parameters then go under urn:ietf:params:oauth:foobar Ciao Hannes On Jul 9, 2011, at 6:17 PM, Eran Hammer-Lahav wrote: The OAuth WG is looking for assistance from the application area community. OAuth 2.0 [1] defines a URI-namespaced method for defining extension grant types[2]. The first specification to use this method needs to pick a URI identifier for using SAML assertions [3]. Options proposed: urn:oasis:names:tc:SAML:2.0:assertion urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer http://oauth.net/grant_type/saml/2.0/bearer Is there a BCP established for this? We need to pick a value quickly and move on. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] SAML Assertion Draft Items
WG, Unfortunately I will not be at IETF#81 and will probably not be able to post a new draft of draft-ietf-oauth-saml2-bearer prior to the I-D submission cutoff date. In lieu of that, I'd like to make a few proposals and/or ask a few questions regarding the next draft in hopes of fostering some productive discussion. Item 1: Profiling of draft-ietf-oauth-assertions Assuming the WG continues to support draft-ietf-oauth-assertions, the SAML draft should become a profile/extension of it. For SAML as a grant type, that should be easy and even shorten/simplify this draft. However, the SAML draft does not currently cover SAML for client authentication and profiling draft-ietf-oauth-assertions would suggest that it should. Is there any general consensus as to if SAML should be profiled as a client authentication method? It is certainly feasible but might require restructuring and retitling the draft. Item 2: URI(s) The value for grant_type is currently defined as http://oauth.net/grant_type/saml/2.0/bearer but there have been some questions raised about the stability and appropriateness of the URL. I really did read RFCs 2648 3553, as was suggested at the last F2F meeting, but it's not clear to me how to register an IETF URI and/or if those RFCs are fully appropriate for this. If someone could explain it to me in terms my preschooler could understand, maybe I could jump though the proper hoops to get the URI to be something like urn:ietf:something:something. Otherwise, I can continue to use http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft should also cover client authentication, also define http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version could then follow a similar pattern. Or perhaps we could use the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer subject confirmation method. It seems like that might be close enough to work out without violating anything serious. And it could be used for both grant_type and client_assertion_type, which is nice. Item 3: Processing rules An out of band request came from folks at a large company to change/relax the validation rules in order to allow for interoperability with existing software products. Which seems very reasonable. The change would basically amount to relaxing the MUST on the SubjectConfirmationData element to a SHOULD (or maybe loser even) while adding a requirement for a NotOnOrAfter attribute on the Conditions element (possibly conditionally based on the existence of it, or not, on the SubjectConfirmationData). It's a little hard to explain but hopefully that conveys the idea. It seems like a change that should be made but I wanted to get some feedback from a wider group before doing it. I realize the assertion stuff is secondary to the core protocol for most of you but I that you, if you've read this far, and I welcome and appreciate any thoughts/feedback on these issues/questions. Thanks, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
Yes, I think it would apply to all three (in cases where the value is some reference). I feel like a refresh token should be a little longer but I don't know if that feeling would actually hold up when doing a real threat model analysis. On Wed, Jul 6, 2011 at 9:53 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 06, 2011 8:46 PM To: Oleg Gryb Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Example tokens So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions
I believe the new assertion draft covers it and this change can be sidelined as long as the new draft has WG support to move forward. On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: In light of the new assertion draft, do we still want to make this change? EHL From: Brian Campbell bcampb...@pingidentity.com Date: Tue, 24 May 2011 07:25:12 -0700 To: oauth oauth@ietf.org Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions One of the action items out of yesterday's meeting was to draft some text for a section 4.5.1 in core that defined the optional but recommended use of an assertion parameter for extension grants where the use of a single parameter to carry the grant/assertion was possible. Below is a first cut at some proposed text that hopefully avoids some of the awkwardness that EHL described in previous attempts to introduce such a parameter. Comments or edits or editorial improvements are, of course, welcome. But I think this hopefully captures the intent of what was discussed yesterday (and before). If we get some consensus to make this change, I think a couple of other actions are implied. - The IANA assertion parameter registration request (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) should be removed from the SAML draft and put into http://tools.ietf.org/html/draft-ietf-oauth-v2 - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec will change the parameter it uses from jwt to assertion and drop the registration request for jwt (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) --- proposed text for sections 4.5 4.5.1 --- 4.5. Extensions The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the grant_type parameter of the token endpoint, and by adding any additional parameters necessary. If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2. 4.5.1 Assertion Based Extension Grants If the value of the extension grant can be serialized into a single parameter, as is case with a number of assertion formats, it is RECOMMENDED that that a parameter named assertion be used to carry the value. assertion REQUIRED. The assertion. The format and encoding of the assertion is defined by the authorization server or extension specification. For example, to request an access token using a SAML 2.0 assertion grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client makes the following HTTP request using transport-layer security (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- ___ 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] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions
Either way. It could stay in there, if you want to show a concrete example of an extension grant type. Or it could be removed too - draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer will have plenty of examples. On Mon, Jul 4, 2011 at 12:54 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: What about the example using SAML assertion? From: Brian Campbell bcampb...@pingidentity.com Date: Mon, 4 Jul 2011 11:42:21 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions I believe the new assertion draft covers it and this change can be sidelined as long as the new draft has WG support to move forward. On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: In light of the new assertion draft, do we still want to make this change? EHL From: Brian Campbell bcampb...@pingidentity.com Date: Tue, 24 May 2011 07:25:12 -0700 To: oauth oauth@ietf.org Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions One of the action items out of yesterday's meeting was to draft some text for a section 4.5.1 in core that defined the optional but recommended use of an assertion parameter for extension grants where the use of a single parameter to carry the grant/assertion was possible. Below is a first cut at some proposed text that hopefully avoids some of the awkwardness that EHL described in previous attempts to introduce such a parameter. Comments or edits or editorial improvements are, of course, welcome. But I think this hopefully captures the intent of what was discussed yesterday (and before). If we get some consensus to make this change, I think a couple of other actions are implied. - The IANA assertion parameter registration request (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) should be removed from the SAML draft and put into http://tools.ietf.org/html/draft-ietf-oauth-v2 - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec will change the parameter it uses from jwt to assertion and drop the registration request for jwt (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) --- proposed text for sections 4.5 4.5.1 --- 4.5. Extensions The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the grant_type parameter of the token endpoint, and by adding any additional parameters necessary. If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2. 4.5.1 Assertion Based Extension Grants If the value of the extension grant can be serialized into a single parameter, as is case with a number of assertion formats, it is RECOMMENDED that that a parameter named assertion be used to carry the value. assertion REQUIRED. The assertion. The format and encoding of the assertion is defined by the authorization server or extension specification. For example, to request an access token using a SAML 2.0 assertion grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client makes the following HTTP request using transport-layer security (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- ___ 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
