Forgot to mention that I don't have any outstanding comments in my queue so if
your feedback was not incorporated into -12, and you feel strongly about it,
bring it up again.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hamm
Whoever is working on the security considerations section, please add this to
your list.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Saturday, July 10, 2010 11:44 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG]
Brian,
Thank you for pointing me to the SAML Bearer Assertion Grant Type Profile. I
understand now. Maybe the spec would be clearer if it said that the client
assertion is a bearer assertion.
Francisco
--- On Thu, 1/20/11, Brian Campbell wrote:
From: Brian Campbell
Subject: Re: [OAUTH-WG]
Draft -12 is finally out.
This is almost a complete rewrite of the entire document, with the primary goal
of moving it back to a similar structure used in -05. I have been thinking
about this for a few months and finally came up with a structure that combines
the two approaches.
The draft incl
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : E. Hammer-Lahav, et al.
Filena
Please let me know if -01 addresses your concerns.
EHL
> -Original Message-
> From: Richer, Justin P. [mailto:jric...@mitre.org]
> Sent: Monday, January 10, 2011 5:46 AM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: OAuth MAC token type draft
>
> Right -- if you substitute "token" wit
Sorry, typo ... see clarification below.
Phil
phil.h...@oracle.com
On 2011-01-20, at 2:50 PM, Phil Hunt wrote:
> I don't think this is a case of providing alternative methods. It is just a
> case of allowing ANY method that the Authentication server deems sufficient.
> Kerberos, SAML, SSO
I don't think this is a case of providing alternative methods. It is just a
case of allowing ANY method that the Authentication server deems sufficient.
Kerberos, SAML, SSO token, basic auth, mutual SSL, etc.
Thus you don't need to put specific authentication methods in the spec other
than to
Francisco,
While a proper profiling of subject confirmation is generally needed for a
secure/interoperable SAML exchange, it's worth noting that assertions as
used in OAuth (client assertions or URI/assertion grant types) are not
necessarily SAML assertions. The term assertion is used more genera
On Thu, Jan 20, 2011 at 2:25 PM, Brian Campbell
wrote:
> Okay, sorry, I see the distinction you were making. The client could
> potentially be told the client_assertion_type and given the assertion
> (assuming it's properly encoded for all the hops) by some IdP/STS and make
> use of the use of th
On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt wrote:
> The client does need to know how to authenticate. But given that it already
> has to know a lot about the service, you would think acceptable
> authentication types are well known to the client.
Yes, true.
> What is the problem with the c
Okay, sorry, I see the distinction you were making. The client could
potentially be told the client_assertion_type and given the assertion
(assuming it's properly encoded for all the hops) by some IdP/STS and make
use of the use of the spec, as it is written in -11. Maybe then some
clients could
The client does need to know how to authenticate. But given that it already has
to know a lot about the service, you would think acceptable authentication
types are well known to the client.
What is the problem with the client authenticating like any normal web service
client? (IE outside of o
On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell
wrote:
> I'd argue that, for reliable interoperability, both of those cases would
> require an extension or at least some level of agreement about the format
> and validation rules of the assertion.
I do agree that an extension would be useful for t
I'd argue that, for reliable interoperability, both of those cases would
require an extension or at least some level of agreement about the format
and validation rules of the assertion.
On Thu, Jan 20, 2011 at 2:08 PM, Marius Scurtescu wrote:
> On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav
On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav wrote:
> Client assertion credentials:
>
> The mechanism is under specified, especially in its handling of the
> client_id identifier (when used to obtain end-user authorization).
> It does not contain any implementation details to accomplish any
Having thought about it, I'm willing to remove the text below. Are there any
other sections of the bearer token security considerations that you believe
belong in the framework spec rather than the bearer token spec, or that don't
belong at all?
Very cool!
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
axel.nenn...@telekom.de
Sent: Thursday, January 20, 2011 9:39 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] JSON Web Token Java implementation
My java code for implementing the new JSON We
OK, looping in Chuck, Luke, and Brian.
Do you all remember the discussion we had a few months ago about
having the user-agent profile return a verification code in the
fragment? The middle of the discussion thread is here:
http://www.ietf.org/mail-archive/web/oauth/current/msg02680.html
Do any o
My java code for implementing the new JSON Web Token draft-01
http://self-issued.info/docs/draft-jones-json-web-token-01.html
is ready and commited to the openinfocard source code repository.
JUNIT tests are here:
https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/x
mldap/js
Yes, host-meta is definitely in play. I do want the SASL profile to be able to
specify discovery info in-band too though. So the discovery returned in the
SASL profile might be a host-meta indication or it might be the relevant
contents if the SASL profile wants to override what might be norma
21 matches
Mail list logo
