How about a few min on proof-of-possession requirements? I can present our use
cases and requirements
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Friday, July 13, 2012 4:42 PM
To: Hannes Tschofenig; oauth@ietf.org WG
Subje
I will not be at CIS
Sent from my Windows Phone
From: John Bradley
Sent: 7/15/2012 10:59 AM
To: Phil Hunt
Cc: Anthony Nadalin; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested
Good working with you and Tony is the
You providing beer?
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Monday, July 30, 2012 9:33 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Informal OAuth Chat @ IETF#84
Hi all,
for those who are attending the IETF m
I think that there is also the Proof Key observation for Proof of Possession
that needs to be included:
When creating response, the AS encrypts both the token and the proof key within
it using the public key of the RS. The AS also includes the proof key in the
response and encrypts it using the
I agree that HOK may be independent of MAC and should be a separate issue, as
MAC does not solve my proof of possession for a HOK solution
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
William Mills
Sent: Monday, November 26, 2012 10:42 AM
To: Phil Hunt; Sergey Beryoz
It seems premature and we should consider this in the bigger context of the "on
behalf of"/delegation work that has been started
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, December 18, 2012 6:22 PM
To: oauth
Subject: [OAUTH-WG] "cid" cla
I can't see how you think PRN is way under defined when SUB is not
From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Wednesday, December 19, 2012 11:43 PM
To: Mike Jones
Cc: Anthony Nadalin; John Bradley; oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT
As "prn"
Concern here is that value could be an “interpretation” and thus you may get
different results that you don’t get when it’s a URI
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Wednesday, December 26, 2012 10:46 PM
To: Mike Jones
Cc: oauth@iet
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 Ass
By definition a claim is always in doubt thus it would not call it a credential
until it is verified
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Chadwick
Sent: Saturday, December 29, 2012 1:42 AM
To: Mike Jones
Cc: IETF oauth WG
Subj
arty (or by
a verifier acting at the request of the relying party).
From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Saturday, December 29, 2012 8:04 PM
To: Anthony Nadalin
Cc: David Chadwick; Mike Jones; IETF oauth WG
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
T
Mike, claims are in doubt thus they have to be verified thus they don’t carry
the proof
From: Mike Jones
Sent: Saturday, December 29, 2012 11:54 PM
To: Nat Sakimura; Anthony Nadalin
Cc: David Chadwick; IETF oauth WG
Subject: RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
The problem
Nope, disagree as a claim is always in doubt thus it has no proof, the proof
comes in the verification
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Sunday, December 30, 2012 12:20 AM
To: Anthony Nadalin
Cc: Mike Jones; IETF oauth WG
Subject: Re: [OAUTH
Is "authorization" the best choice here over "access grant" since it's really
not authorization that is being revoked it's the grant
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To:
Why not just have a physical and logical endpoint options
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Wednesday, January 23, 2013 7:47 AM
To: Nat Sakimura
Cc: Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concern
Registration has to work in a multi-tenant environment so flexibility is needed
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG
e.org]
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
I completely disagree with this assessment. Multi-tenancy will work just fine
(or even better) if everyone uses the same pa
Review:
1. Since not stated I assume that the Revocation Endpoint can exist on a
different server from the Authorization server (or is it assumed that they are
1), if so how is the Revocation Endpoint found?
2. Any token type that is supported can be revoked, including refresh
tok
that revoking 1 token
revokes other tokens thus the client would have to know the servers policy.
This should be a SHOULD not MUST
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 6:17 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subjec
entence, only the token I sent or any revoked token. Also how do I
know when the token is actually revoked, could take a week or more given
policy?
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc: oauth@i
7;s a policy choice in the specification and thus the
issues that this creates. Basically revocation is not well defined in this
specification which leads to many issues
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 8:55 AM
To: Anthony Nadalin
Cc: oauth@ietf
new text
6. I think clarifying words would help here
7. I prefer the wording you responded with and not the current text as it puts
a requirement on the client
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Saturday, January 26, 2013 10:33 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
:20 AM
To: Shiu Fun Poon
Cc: Anthony Nadalin; Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Hi.. Tony.. You are able to present this better than I do.
Justin,
Currently as it is, the spec is unflexible. So when I send a request to an
endpoint, the endpoint
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Thursday, February 18, 2010 9:14 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] WG Survey
A few questions we should answer before moving forward. Considering *your*
What the specification allows in terms of SSL is different than deployment
requirements, so I would not say that Microsoft is generally comfortable in not
using SSL. We don't have a specific requirement for signatures.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun..
My design principles would be the following as we already have protocols that
solve many complex usecases
1. Simple programming model
3. Reduce deployment barriers
2. Limited or no client side code (works with a browser)
3. Replace username/password scenarios
4. No client side key distributio
I don't think that Microsoft ever indicated that we need the SAML flows.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Tuesday, March 23, 2010 10:48 AM
To: Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
S
Yes the flows are interesting and we would be willing to work on them
-Original Message-
From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Wednesday, March 24, 2010 9:11 AM
To: Anthony Nadalin; David Recordon; Torsten Lodderstedt; Mark Mcgloin
Cc: OAuth WG
Subject: RE
So I doubt that the client always knows what the server supports, the server
should be open in allowing all parties to find out what is supported
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Tuesday, March 30, 2010 5:44 PM
I'm not sure if you are coming from the user or service perspective. So if a
user asks for HTTPS do you have to support HTTPS? If a service asks for HTTPS
do you have to support it? Or do you just fail?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Allen
Tom
Sent: T
> Why is the native application launching a browser with a protected resource
> request? That seems odd.
Not odd at all a lot of the Eclipse applications can work this way
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Thursday, April 08, 2010
I would actually like to see the inclusion of reference tokens here also, I do
think that the 255 character limit is too restrictive and needs to be revisited.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Friday, April 09,
+1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Friday, April 09, 2010 11:57 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?
+1 no restriction, please
256 is much too short
Am 10.04.2010 07:16
> I'm strongly opposed to writing a spec that must be profiled in order to be
> implemented and the proposed definition of the scope parameter mandates
> profiling the spec.
I'm strongly opposed to having a specification that can't be used because it's
so restrictive
From: oauth-boun...@ietf.o
It would be useful to understand the token type as the AS and RS server may
each generate and accept different token types
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Andrew Arnott
Sent: Friday, June 04, 2010 6:43 AM
To: George Fletcher
Cc: OAuth WG (oauth@ietf.org)
> If a server needs to verify, it can literally iterate over all of the keys
> associated with the client until it finds the right one.
Depends on how the server stored the keys, this can be a very expensive
operation w/o a key_id to match/index on
-Original Message-
From: oauth-boun...
There are many cases where we need to have more than 1 SAML assertion be used
to represent the authorization token, so would want a provision for multiple
SAML tokens and not sure it makes sense to have a separate profile for that or
add it as an option here.
-Original Message-
From: oa
ultiple subject confirmations.
On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin wrote:
> There are many cases where we need to have more than 1 SAML assertion be used
> to represent the authorization token, so would want a provision for multiple
> SAML tokens and not sure it makes sense to
[mailto:bcampb...@pingidentity.com]
Sent: Tuesday, August 03, 2010 1:12 PM
To: Anthony Nadalin
Cc: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
Seems like a much more complicated scenario. Allowing more than one assertion,
off the top of my head, would necessitate
Seems that ISO/IEC 24760 is yet another one that does not align with
Recommendation X.1252 (IdM terms)
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor
Faynberg
Sent: Wednesday, August 11, 2010 10:42 AM
To: Tschofenig, Hannes (NSN - FI/E
ameters sent without
> a value MUST be treated as if they were omitted from the request. The
> authorization server SHOULD ignore unrecognized request parameters."?
>
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the a
: Friday, August 20, 2010 2:11 PM
To: Anthony Nadalin; Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] more than one assertion?
This is a convincing use in support of the multiple assertions.
My understanding is that in the use case the two assertions provide the
tokens,,
this winds up being more complicated and traffic, the reason to not send
directly is for user consent.
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, August 20, 2010 11:29 AM
To: Anthony Nadalin
Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
Using the native client would be one way to acquire the user consent.
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Tuesday, August 31, 2010 12:36 AM
To: Anthony Nadalin
Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
Subject: Re: [OAUTH-WG] more than one
Might actually want both @ same time, so might be better to expand
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of hdknr
hidelafoglia
Sent: Tuesday, September 21, 2010 12:39 PM
To: Yaron Goland
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth Signature
Eric, Microsoft shares some of the same views, we would like to see the WG
charter expanded to cover these additional items (so we have a home for these),
we would like to see that proposed and agreed upon at the November meeting if
at all possible.
From: oauth-boun...@ietf.org [mailto:oauth-bo
I have not seen the support to bring signature support back into core, have not
seen the public response either, all I have seen is you raising this as an
issue. We should keep the original agreement to move signatures out of core,
there is enough activity on signatures that we are confident tha
So we have been working with Nat on the signature proposal and talking to Nat
he agrees that the JWT proposal is well under way, what I would like to make
sure is that we merged in with your proposal
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dirk
Balfanz
Sent: Mo
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
complete, there are previsions to use SSL, if one needs to go beyond this then
a reference to the signature specification would be in the security
Not seeing an overwhelming support for doing this, how many interoperable
deployments of 1.0a signature are there?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Sunday, September 26, 2010 11:44 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-W
Still no real answers ...
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, September 27, 2010 9:46 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: RE: Proposal: OAuth 1.0 signature in core with revision
You must be joking about 1.0a signature deployment. It's
I agree bearer tokens are already in wide usage, I think it makes sense to have
a default interoperable token type, much like a token format and signature. The
security considerations section can point/cover any issues.
I'm not seeing what the splitting of the document is achieving except side
> So this one I do feel more strongly about: We should only include crypto
> mechanisms that everybody MUST support. Otherwise, we'll have to invent some
> sort of negotiation step in the protocol: "do you support alg XYZ? No I
> don't, > please use ABC". Let's not do that.
>As just one datapoi
:balf...@google.com]
Sent: Friday, October 01, 2010 8:45 PM
To: Yaron Goland
Cc: Anthony Nadalin; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland
mailto:yar...@microsoft.com>> wrote:
No matter what algorithm or key size
: Wednesday, October 06, 2010 2:26 PM
To: Anthony Nadalin
Cc: Yaron Goland; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
So what's the proposal, then? That OAuth service providers document what crypto
mechanisms they support? And developers will just have to
It has been quiet here, so
1. Did we get agreement to the document split (assume so as I did not see
any negatives), if so when can we expect draft 11 or the core and the 1st draft
of the new document?
2. Did we get editor(s) assigned to the new document?
3. Will there be a
Sampo, can you give a usecase of how you would use the pairwise
-Original Message-
From: openid-specs-ab-boun...@lists.openid.net
[mailto:openid-specs-ab-boun...@lists.openid.net] On Behalf Of sa...@zxidp.org
Sent: Tuesday, October 26, 2010 6:40 PM
To: Mike Jones
Cc: sa...@zxidp.org; open
correlation unless the user decides to permit
discovery.
The model if not the details seem similar to some work that is being submitted
to the ITU-T as I understand it.
John B.
On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote:
> Sampo, can you give a usecase of how you would use the pairw
Can't really comment on product futures but Messenger Connect already has WRAP
support and ACS has Oauth 2.0 v10 support but there seems to be a trend here
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of hank
williams
Sent: Friday, October 29
: John Bradley [mailto:jbrad...@mac.com]
Sent: Thursday, October 28, 2010 5:22 PM
To: Anthony Nadalin
Cc: the Connect work group; sa...@zxidp.org; openid-specs...@lists.openid.net;
oauth@ietf.org
Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery
If there is no authorization mechanism
Like an XML parser
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, October 29, 2010 9:24 AM
To: Anthony Nadalin; John Bradley
Cc: sa...@zxidp.org; openid-specs...@lists.openid.net; the Connect work group;
oauth@ietf.org
Subject: RE: [OAUTH-WG
I was looking for less of an analysis and more of considerations (of the
current flows and actors), I'm not sure how to adapt what you have done to
actually fit in the current specification, was your thought that you would
produce a separate security analysis document?
-Original Message
Cc: Anthony Nadalin; Tschofenig, Hannes; ab...@ietf.org; r...@ietf.org;
i...@ietf.org; sec...@ietf.org; web...@ietf.org; x...@ietf.org;
kit...@ietf.org; i...@iab.org Board; i...@ietf.org; oauth@ietf.org
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
I would say
--Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Tuesday, November 09, 2010 11:14 PM
To: oauth@ietf.org
Cc: Nicolas Williams; Anthony Nadalin; Tschofenig, Hannes
Subject: Re: [kitten] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
Am 10
Concern here is that HTTP Basic Auth provides a straightforward interop profile
for the web server profile
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richer, Justin P.
Sent: Monday, January 17, 2011 7:43 AM
To: Eran Hammer-Lahav; OAuth WG
Agree that these would be code breaking changes and cause interoperability
issues late in the specification cycle
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: [OAUTH-
I also support option #1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Campbell
Sent: Sunday, January 16, 2011 7:29 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote
by 1/17
I guess I'm in the minority but I prefer
If it is left as optional (not removed) then I'm OK to go with parameter-based
approach as default
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, January 18, 2011 9:50 AM
To: Anthony Nadalin; Richer, Justin P.; OAuth WG
Subject: RE: [OAU
We should then have a consensus call to remove items like this
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, January 21, 2011 11:11 AM
To: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action:draft-iet
I don't understand the rationale for removing the client assertion credentials,
as client password authentication is left in. Client Password Authentication is
also underspecified as client_secret could be anything that the authentication
server seems fit (raw clear text password, hash, digest,
Based on your logic then Scope, Client Password Authentication, etc, should be
removed. Not sure how leaving the proposed text in would delay things
From: David Recordon [mailto:record...@gmail.com]
Sent: Tuesday, January 25, 2011 5:11 PM
To: Anthony Nadalin; hannes.tschofe...@gmx.net; Eran
, 2011 5:38 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials
Can you share with the list how you plan to use this client assertion
authentication scheme?
Which of the authorization grant types you will use it with?
Will you use it with the authorization endpoint
drop it is just
poor practice.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, January 25, 2011 6:11 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Removal: Client Assertion Credentials
Scope was discussed in detail, including use cases and implementation
: Wednesday, January 26, 2011 2:51 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials
Can you explain how having to define *two* extension parameters makes the
specification useless? The bearer token specification is going to define its
corresponding WWW-Authenticate
There have been several of us that have objected and several of that have
implemented this feature, it's late in the cycle to remove, so I raise the
objection.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Thursday,
#1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Tuesday, February 08, 2011 3:05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12
Given that people are clearly voting to change the bearer token scheme na
Nice job Phil
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil
Hunt
Sent: Monday, February 21, 2011 4:46 PM
To: OAuth WG
Subject: [OAUTH-WG] Flowchart for legs of OAuth
FYI. I published a blog post with a flow-chart explaining the legs of
Torsten, Mike Jones and I will be there all week, it might be good to setup
some time to go through the Security Considerations draft
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Friday, March 11, 2011 1:15 AM
To:
> Why the early cut-off date? As this is in advance of IETF 80, changes will
> wait until after Prague in any case.
To inform the discussions @ IETF 80 to determine what else might be needed,
which goes to your second comment
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-
My preference would be option A
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Friday, March 11, 2011 3:04 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday,
March 18
As you know, the OAuth 2.0 Bearer T
Is it possible to add these to the mix?
http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt
and also the http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.txt
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tsch
I think it does for example how one might discover the authorization service
and this would be a forum to see if others also do or not.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, March 17, 2011 11:56 AM
To: Anthony Nadalin; Hannes Tschofenig
...@hueniverse.com]
Sent: Thursday, March 17, 2011 3:58 PM
To: Anthony Nadalin; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] Agenda Proposal
This proposal goes far beyond just solving any discovery needs for OAuth. It
also directly competes with existing (deployed) proposals. This group is not
the
Will do as I think the system opens back up on the 28th
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Friday, March 18, 2011 11:22 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Agenda Proposal
Hi Tony,
please
in the poll I conducted on the OAuth Errors Registry:
For A:
Mike Jones
Igor Faynberg
Justin Richter
Anthony Nadalin
For D or C:
Eran Hammer-Lahav
William Mills
Given that twice as many people indicated a preference for
What I'm hearing is that some folks feel that we will ever have any OAuth
Extensions and anything that extends OAuth can do whatever it likes and we
don't want to have any conventions dictated by the base.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, March 22, 20
Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, March 23, 2011 3:30 PM
To: Anthony Nadalin; Phil Hunt; Manger, James H
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry
> -Original Message-
> From: Anthony Nadalin [mailto:tony...@m
> OAuth issues security tokens without indicating where they can be safely
> used. While that fatal flaw remains, it is pointless to specify the use of
> the Origin header.
I don't think anything should be in the base as the different token profiles
can stipulate the audience.
From: oauth-boun
I also object, an error registry the proper approach here.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Thursday, March 31, 2011 11:31 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Error extensibility proposal
way?
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, March 31, 2011 2:43 PM
To: Anthony Nadalin; Mike Jones; OAuth WG
Subject: RE: Error extensibility proposal
'PROPER' REQUIRES USE CASES AND REQUIREMENTS!
You have to show how the pro
This section makes sense as it does setup for the identification and
authentication of the client, so I do believe that it makes sense in the
document. Thomas undertook the task to revive the Client Credentials section
from previous draft that will include normative text, which when asked the r
So the rewrite of the text was given to Torsten and myself as action items, but
welcome others to help out here
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Monday, April 04, 2011 12:06 PM
To: Skylar Woodward; Marius Scurte
> I completely agree with you regarding not being able to authenticate a native
> client.
I suggest you read the security considerations draft to make sure this is
correct and points out the issues
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>"3.3 Client Assertion Credentials". OAuth2 currently supports the concept of a
>client app swapping an assertion for an access token. Do people want the
>additional functionality of using assertions for generic client
>authentication? I assumed servers would >prefer that clients swap an asserti
continue
to say. I think that the text that Thomas has resurrected is just fine and I
would support getting that text back into the document.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, April 18, 2011 3:46 PM
To: Anthony Nadalin; Manger, Jame
: Monday, April 18, 2011 4:10 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3
I don't think you understand what 'breaking' means. Breaking would be if we
assigned a different meaning or syntax to the two parameters, or changed their
name. Breaking r
...@hueniverse.com]
Sent: Monday, April 18, 2011 4:24 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3
At least I finally got you to agree that this can be done in a separate
specification. That's progress.
EHL
> -Original Message-
> From: Anth
ay, April 19, 2011 2:06 PM
To: Eran Hammer-Lahav; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
Resolves *my* confusion. :)
Tony: apologies if you covered this in earlier posts, but if 4.5 does not solve
your use case, would you clarify what else is needed? Are you unhappy
Clarifications
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, April 20, 2011 4:52 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
I had a hard time following some of this but I'll try to clarify.
From: Anthony Nadalin mailto
Some additional input
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, April 21, 2011 12:28 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
This got a little bit too nested so I kept only the comments where we are not
on the same
201 - 300 of 309 matches
Mail list logo
