+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.
--
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
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
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
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
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
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
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
+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:
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
.
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
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
?
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
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
...@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
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
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:
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
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
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:
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
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
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
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
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
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
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
, 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
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
+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
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.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
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
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
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
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
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
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
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
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
#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
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
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
** 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
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
§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
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 [
§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.
*
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
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
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
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
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
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...
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
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.
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
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
:* 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
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
-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
: 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
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.
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
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
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
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
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,
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:
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
+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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
: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
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,
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
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
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.
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,
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
...@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
...@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
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
...@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 Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba barryle...@computer.org wrote:
This document is intended to replace the SAML and Bearer Token
documents, and those two will then be profiles, defining specific
assertion mechanisms.
Just a couple points of clarification
This doc is not related to
[mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Campbell
Sent: Thursday, June 30, 2011 2:11 PM
To: Barry Leiba
Cc: OAuth WG
Subject: Re: [OAUTH-WG] New Assertion Draft for review
On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba barryle...@computer.org wrote:
This document is intended to replace
Maybe this is already a known issue but it just occurred to me that
this draft probably needs to have an IANA Considerations section that
registers the parameters that it defines per registry defined in the
core OAuth spec [1] - assertion, client_assertion_type,
client_assertion.
[1]
invalid_grant seems like the appropriate error as the username and
password are the grant in the context of the Resource Owner Password
Credentials flow/grant type.
On Tue, Jun 28, 2011 at 9:47 AM, George Fletcher gffle...@aol.com wrote:
I'm working on spec'ing out a use of the Resource Owner
1001 - 1100 of 1167 matches
Mail list logo
