Zhou,
The correct addres for Zachary is on the (corrected) CC list.
My take on it is that the Use Cases document has been ready for approval
for quite a while, and there were no concerns about misunderstandings.
The cases are clearly delineated by their respective 1) descriptions, 2)
Mike,
Thanks! This is great news for all of us, and, finally, long-deserved
positive publicity for OAuth 2.0.
Long live OAuth!
Igor
On 5/15/2013 1:24 PM, Mike Jones wrote:
I'm pleased to report that OAuth 2.0 has won the 2013 European
Identity Award for Best Innovation/New Standard. I
Where is the link to some /bottles? /Time to celebrate!
On 5/15/2013 3:57 PM, Mike Jones wrote:
Link to some photos:
https://www.facebook.com/media/set/?set=a.10151577944262856.1073741829.503057855type=1l=4f3fe44c99.
I'll add the official ones from Kuppinger Cole once they're posted.
I chime in in support of option 1. Rationale: nothing is worse than
the presence of an obscure parameter. (Not only it pollutes the
environment, but it is a potential attack vector.) So rather than invent
an acceptable value for it, I would remove it.
Igor
On 1/10/2013 11:59 AM, George
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
in detail
These are, of course, in addition to the original (now pretty old) use
cases doc I've mentioned on this list before:
http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases
Eve
On 18 Oct 2012, at 9:53 AM, Igor Faynberg
igor.faynb...@alcatel-lucent.com
Looks like a good description of a new use case to me!
Igor
On 10/17/2012 10:23 PM, zhou.suj...@zte.com.cn wrote:
Hi, Thomas,
Sorry for reply late. I somehow missed the emails from OAUTH list.
What may not be clear up-front from reading the UMA core spec is that
there are 5 parties
An interesting thought!
It is true that interoperability testing is a requirement for an
advancement of a Proposed Standard to Draft Standard, so surely OAuth
interoperability testing must take place. I I don't recall test suits
defined per se in the IETF. Not that it has not happened--it
+1
Reason: Clarity is always good!
Igor
On 7/28/2012 5:56 PM, Torsten Lodderstedt wrote:
Hi John,
I would prefer to make it a MUST.
regards,
Torsten.
Am 27.07.2012 18:42, schrieb John Bradley:
The text in 3.2.1 is informational to explain why there is a
REQUIRED is in 4.1.3.
Putting the
Oh no... I never even noticed the drama. I thought that everything has
been agreed on...
Igor
On 6/8/2012 5:31 PM, Peter Saint-Andre wrote:
I must say that I found it surprising, too. An explanation beforehand
from the chairs would have helped to prevent confusion.
On 6/8/12 3:28 PM, Eran
+1 on the requirements.
On 4/19/2012 12:48 PM, Mike Jones wrote:
There are two criteria that I would consider to be essential requirements for
any resulting general-purpose discovery specification:
1. Being able to always discover per-user information with a single GET
(minimizing user
+1 for keeping registration and discovery separate.
(As is typical, Torsten had beaten me to saying just what I was thinking
about and preparing to to say. The only consolation is that he
expressed it better than I would have.)
Igor
On 4/18/2012 3:56 PM, Torsten Lodderstedt wrote:
Hi
Hannes,
I took a look (a bit longer than just quick), and what I see
completely coincides with my understanding of the result of the discussions.
Good job!
Igor
On 4/12/2012 6:55 AM, Hannes Tschofenig wrote:
Hey guys
based on the discussion before, during, and after the Paris IETF meeting
To me this looks like more than the same problem being solved--it
appears to be the same protocol... I wonder if, the representation
issues were put aside (i.e., left to the API specification), the common
part is what can be adopted.
Igor
On 4/12/2012 8:01 AM, Stephen Farrell wrote:
On
design differences.
Web Finger without XML is not horrible by any means, but nether is SWD.
SWD is more about users while host-meta is more about server resources.
John B.
On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:
To me this looks like more than the same problem being solved--it appears
Hannes,
Thanks! It is excellent to have a summary like that. (I myself missed a
few event, like Harry's lunch.)
Igor
On 3/20/2012 11:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Hi all,
you may have noticed that a number of events take place next week
related to OAuth:
Sunday:
Phil is right! I observe the same thing: the frond-end is RESTful; the
back-end is mixed. Personally, I think it would be good for OAuth to be
deployed as wide as possible. (The SAML/OAuth ideas I think are
working the same problem.)
Igor
On 3/19/2012 9:23 AM, Phil Hunt wrote:
There's
Looks good and comprehensive to me.
Igor
On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
So, here is a proposal:
---
Web Authorization Protocol (oauth)
Description of Working Group
The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access
Please include me in the chat!
This is, in fact, something that could make a very interesting agenda
item at a meeting.
Igor
On 3/12/2012 12:01 PM, Chuck Mortimore wrote:
Salesforce has an implementation of both the SAML and JWT Bearer
tokens. Happy to chat.
-cmort
On Mon, Mar 12, 2012
Could there be a potential security hole in providing an error
response? (Not that I see it, but many problems in the past had been
caused by helpful responese.)
Igor
On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol. Thta won't include a redirect, and
the
Nat,
Your note made me think (as always), so maybe some text clarification is
indeed in order.
I have a slightly different understanding of the items you brought up.
RFC 1750 is Informational, and I thought (maybe mistakenly?) that it
cannot be used as a norm in a MUST clause. Therefore,
(Strictly editorial.)
Just to make the first sentence easiery to parse, I suggest to clarify
the scope (no pan intended) of MUST. I read it the server MUST either
process the request OR fail it. If so, maybe just inserting the word
either would do the job. I would also change punctuation
Since there is so much agreement and peace in the air, I would through
a little editorial query:
Would it not be better to say the appropriate version instead of this
somewaht lawyerish version (or versions)?
Igor
On 1/20/2012 3:44 PM, Barry Leiba wrote:
Added to section 1:
TLS
+1 for MUST.
In addition, I suggest slight rewarding: the authorization server MUST
include the value of the scope parameter in the response in place of
the authorization
server SHOULD include the scope response parameter
I think there is one parameter, scope, right?
Igor
On
, but corporate decryption proxies are also on the
increase.
AYJ
On 3/01/2012 11:17 a.m., Igor Faynberg wrote:
I am at a loss here; granted, it is a gray area... Does it mean that
RFC 2817 has not been implemented properly?
From RFC 2817:
5. Upgrade across Proxies
As a hop-by-hop
in the form of
reverse-proxies, but corporate decryption proxies are also on the
increase.
AYJ
On 3/01/2012 11:17 a.m., Igor Faynberg wrote:
I am at a loss here; granted, it is a gray area... Does it mean
that RFC 2817 has not been implemented properly?
From RFC 2817:
5. Upgrade across
I am at a loss here; granted, it is a gray area... Does it mean that
RFC 2817 has not been implemented properly?
To make it simple: At the client, I establish a session key with the
server, and then use it for confidentiality. How is this key known to
any proxy?
Igor
On 1/2/2012 7:07 AM,
On 12/30/2011 10:14 PM, Amos Jeffries wrote:
Reading section 2.3, it appears this method of transferring the
credentials is open to replay attacks when caching TLS middleware is
present. I believe this spec should mandate cache controls on
responses using that method. Otherwise a lot
Many thanks for pointing this! It is *absolutely* (not probably)
worth studying.
Igor
On 10/26/2011 6:31 PM, John Bradley wrote:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
It is essentially a standardization of the method we are using in
openID Connect to make
I agree.
To this end, are we going to have a rechartering discussion? I would
very much support that. We have a number of things waiting, discovery
being one of them.
Igor
On 10/20/2011 1:18 PM, Hannes Tschofenig wrote:
the past that the JSON signature encryption work would go into JOES
Yes, this is high time to have this a WG item!
Igor
On 9/16/2011 3:32 PM, Torsten Lodderstedt wrote:
Hi all,
I just published a new revision of the token revocation draft. We
added JSONP support (thanks to Marius) and aligned the text with draft
21 of the core spec.
We would like to bring
+300 (if I can do that) to indicate my strong agreement. But if somehow
it is decided to add a few sentences on saying that OAuth cannot deal
with key-logging, I will insist on adding two sentences each on OAuth
being unable to deal with 1) earthquakes, 2) certain contageous
diseases, etc.,
Good eye! Seeing this now, I agree, but I admit I never fully
understood what embedded uses-agents were before.
Igor
On 9/6/2011 11:52 PM, Manger, James H wrote:
A strange aspects of this thread is that the current draft already talks about
exactly this issue:
draft-ietf-oauth-v2-21
On 9/6/2011 2:23 PM, Michael Thomas wrote:
...
How, exactly, is the user supposed to protect themselves against rogue
apps?
...
There are a number of ways: 1) Buy shrink-wrapped software only, 2)
Inspect the source code of every application, etc... The mobile network
providers solve
, is the user supposed to protect themselves against
rogue apps?
It sounds like the solution is to tell them to never use oauth in an
app at all.
Is oauth only intended to be used on standalone trustable web
browsers? I don't recall
seeing that anywhere.
Mike
EHL
On Sep 6, 2011, at 11:10, Igor
On 9/6/2011 3:36 PM, Justin Richer wrote:
...
OAuth *does* work with phone apps, and it's a misnomer to say that it's
not a good idea in such environments.
To support and amplify Justin's point, OAuth has been adopted by OMA and
WAC, and ITU-T is developing an OAuth profile. Mobile
Bravo! This has been project-managed masterly.
Igor
On 8/24/2011 8:32 AM, Barry Leiba wrote:
On Mon, Aug 22, 2011 at 1:53 PM, Barry Leibabarryle...@computer.org wrote:
I intend to add the following to the response to this item:
The working group understands that client code needs to know
This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others
(Phil, Tony,Barry) and all agree with it.
Maybe my e-mail was lost, but I was and still am among those who have agreed
with the text, as I am sure many others have
What is also important is that no one has
+1 (against the removal)
On 8/18/2011 12:58 PM, Anthony Nadalin wrote:
Agree, against the removal of text
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Lodderstedt, Torsten
Sent: Thursday, August 18, 2011 1:01 AM
To: Eran
Barry,
I personally think that this is both a very thorough and very timely
follow-up.
(You may consider a minor editorial: As this writing in the first
answer, should be As of this writing. Could not catch anything else.
The only other suggestion is that maybe the response could omit RFC
Precisely! In fact the anonymity of this sort can be achieved even
without a refresh token: as long as the end user is not required to
authenticate to the client.
But for all I remember, we have never had a SINGLE USE CASE (sorry to
transition to my pet peeve) that required anonymity. The
I thought my job was here. Jerome
will pick this conversation from now on.
Igor
On 7/1/2011 5:53 PM, Igor Faynberg wrote:
Torsten,
With many thanks for the note, I think it would be great if you
documented the implementation report in an Informational RFC. In
particular, the SIM-based
On 6/16/2011 4:51 PM, Brian Eaton wrote:
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
If those people have reasonable means in place to protect secrets
on deployment channels and in the local installation - fine. I
I agree with the factual information, but I disagree with the conclusion.
Indeed, there were postings from people who will bake secrets into
installed applications. But there have also been postings from people
(like Torsten and me) who said they will use real secrets and rely on
them.
I
+1
Igor
Torsten Lodderstedt wrote:
Hi,
I also see the need to request and issue multiple tokens in a single
authorization process. There has already been some discussion about
this topic roughly a year ago:
- http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
-
Actually, for the devices that use smart cards (mobile devices, in
particular), this assumption is quite appropriate.
Igor
Thomas Hardjono wrote:
...
However, there is indeed the assumption in Kerberos/RFC4120 (and in the original
Needham-Schroeder protocol) that the client can keep
Thomas Hardjono wrote:
(a) Oauth2.0 today is designed for low-assurance environments.
I don't think that was an objective. At least, the charter does not say
that...
So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just
: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 3:31 PM
To: Thomas Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Actually, for the devices that use smart cards (mobile devices, in
particular
access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.
/thomas/
__
-Original Message-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 3:31 PM
To: Thomas
-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Tuesday, May 31, 2011 6:15 PM
To: Eran Hammer-Lahav
Cc: Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Maybe... But this information must be captured somewhere, right?
At the moment
We have had a long discussion in the beginning on the OAuth analogies
with Kerberos. I always thought that the topic of this thread is EXACTLY
a case for import from Kerberos (which does rely on timestamps).
Kerberos has been successfully deployed for a long time. But Kerberos
has solved the
...Sorry to turn the question around so as to underline my pet peeve:
Have we *documented* all cases? (This is what the Use Cases document is
supposed to be all about.)
Just to clarify: I am not arguing with Phil's point now. I just stress
that as of this moment we don't have anything to
wrote:
I think the use case document should focus on v2, not on MAC. At some point, it
becomes impractical to keep every use case discussed on this list recorded.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Igor Faynberg
Sent
Actually, I would go even further: Provide a list of different ways of
redirecting and address each of them, or at least each class of
redirects with the same characteristics.
Igor
Anthony Nadalin wrote:
The OAuth spec is somewhat silent about how a resource provider should
perform a
Brian Campbell wrote:
Currently (draft -16) client_id is listed as a required parameter for
access token request to the token endpoint for all grant types except
for extensions. In section 3 there is some disposition of the use of
client_id as a means of identification and then, in 3.2, a
As promised, here is a good description:
http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/.
Igor
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
The approach looks right to me; the key is that the 1.0 state machine is
rather simple. A priori, I don't see the 2.0 as more complex (even
though it involves an additional machine), and I think it should be
straight-forward to build the machine and run the reachability analysis
on the system
Mark,
Many thanks for posting this. I am thinking of the next step.
This paper proposes to use the Password-Based Asymmetric Key Exchange
protocol. Many messages ago, I had proposed to use the Password-Based
DH key exchange for the symmetric key generation.
Another option is to mandate
Barry,
Thanks for considering my proposals.
I am happy with the encompasses, and I agree that it is better than
supports.
I think I don't understand the reason why the use cases are not going
to be part of the new charter (or maybe I misunderstood what subsequent
rechartering means).
The
Barry,
I agree. Indeed, after ascertaining that the next rechartering is
scheduled for October, I personally see no problem with deferring the
use cases. (I thought that the current rechartering was already
post-2.0, which is what had confused me.)
With thanks for thorough follow-ups,
to the IESG.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Igor Faynberg
Sent: Monday, May 09, 2011 12:18 PM
To: Barry Leiba
Cc: oauth@ietf.org; oauth-...@tools.ietf.org
Subject: Re: [OAUTH-WG] Revised Charter
Barry,
I agree. Indeed, after
Blaine,
Looks very good to me.
A small editorial suggestion: Rather then say that OAuth consists of
mechanisms, I would suggest saying OAuth supports these mechanisms.
I alsonote the omission of the use cases. I suggest adding an item,
Submit OAuth Use Cases.George, Torsten, and
Good eye! (And an excellent point.)
Igor
Paul Madsen wrote:
but you are describing the protocol in the paper, not the group
A reference like 'The Open Web Authentication (OAuth) protocol [1]'
to
[1] E. Hammer-Lahav, D. Recordon, and D. Hardt, “The OAuth 2.0
Authorization Protocol,”
is
It appears to me that the first part of the draft is an OAuth tutorial,
while the last part is written in shoulds. While a discussion of the
user interface issues is interesting, I strongly believe that it is out
of scope of OAuth. Other than that, I don't see anything that stands
out as
This made me recall a formula from a middle-school textbook on physics
or something:
(IAB/I)*P = PAB.
Hint: I think in that Hilton they deliver beer to any room.
Igor
Hannes Tschofenig wrote:
...
Depending on the number of people and your exact goals you can either go to a pub or I could
Peter,
Could you please advertise the room when it is reserved?
With thanks,
Igor
Peter Saint-Andre wrote:
On 3/11/11 9:10 AM, Anthony Nadalin wrote:
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
in
between or after the meetings. (We did that a few years ago when the
IETF met in Prague.)
Just a thought...
Igor
Peter Saint-Andre wrote:
On 3/11/11 12:10 PM, Peter Saint-Andre wrote:
On 3/11/11 11:44 AM, Igor Faynberg wrote:
Peter,
Could you please advertise the room when
I vote (A) because 1) I strongly believe in modularity and 2) I disagree
with D. Hence what applies to all specifications must be defined at the
highest level, rather than in a self-contained specification. So, this
looked like a simple matter to me.
Having said that, I note that Lucy has a
+1
Igor
Torsten Lodderstedt wrote:
...
I'm in favour to add the refresh token parameter to the implicit grant
flow as it would make it more useable for native apps.
___
OAuth mailing list
OAuth@ietf.org
Cannot help harping... It is exactly this type of a question that Phil
asked that makes a document on the use cases necessary!
Igor
Phil Hunt wrote:
...
What was the original case for this flow? That should point us as to why the
separate flow and whether refresh makes sense given the
Kristoffer,
I assume you mean an interface between the authorization server and the
resource server. If so, I believe it definitely merits a serious
discussion, and I support the idea in principle.
On this subject, I think we need even more work defining the token and
linking it to the
(How pleasant it is to agree with everyone!)
+1
Igor
William Mills wrote:
+1 for reserving the legacy behavior as well.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Thursday, February 03, 2011 10:15 AM
To: Mike Jones
Interesting! I definitely see value in this, and... this appears to
me to be a new use case.
Gabriel Klein wrote:
Dear oAuth2 team,
I'm currently working on the way we will implement oAuth2 in our
company. (Poken.com)
I've an interesting flow to work on:
We delegate the account creation
Eran,
I still don't understand, sorry.
Here is the scenario: When a principal that impersonates the resource
server gets a token (already signed and ready to go, of course) it can
present it to the real resource server and get access to resources.
This is what I thought Torsten meant by
I just wanted to bring these points up, but Torsten got there first!
It only remains for me then to +1 on both.
Igor
Torsten Lodderstedt wrote:
Eran,
- Authentication schemes
You propose to use the authentication scheme name OAuth2 for the
WWW-Authenticate header but another scheme name MAC
James,
Yes, I understand you now and I agree with you.
With thanks,
Igor
Manger, James H wrote:
Igor,
Adding client_id here is unnecessary (the server can include it
in the token if it is convenient for protected resources), and harmful
(it means the protocol that uses the
James,
Could you please clarify the last point (i.e., cannot look like a
normal authentication protocol)? I simply don't understand what you mean.
With thanks,
Igor
Manger, James H wrote:
Adding client_id here is unnecessary (the server can include it
in the token if it is
Abstain. (The reason: I cannot predict how the tokens will evolve.)
Igor
On Thu, 2010-12-02 at 16:04 -0500, Eran Hammer-Lahav wrote:
I'm defining a new token type: MAC based on my previous HTTP Token
authentication draft (which in turn was based on 1.0a HMAC-SHA1). This is being
drafted
no definition of scope.
=nat
On Sat, Nov 27, 2010 at 5:26 AM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
In the context of Martin's question (which concerns end-users understanding
and resulting actions), I interpret the citation as follows: The end-user
has no control over
In the context of Martin's question (which concerns end-users
understanding and resulting actions), I interpret the citation as
follows: The end-user has no control over the value of the scope
parameter, and, given that it is defined by the authorization server,
the end-user is not expected
Alastair,
My (strong) opinion is that the terms resource owner and end user
are not interchangeable.
In the interest of extensibility, we should foresee a situation that
will involve more than one end users, of which some may not necessarily
be resource owners. In fact, I would prefer not
(With apologies for bringing up a tangential matter...)
Talking about the OAuth model, I still see here Client instead of
Consumer. I thought there was an agreement on the terminology
change. I have no specific preference for either term, but I think it
is essential that our terminology be
Hannes,
As it might be expected, I am interested in discussing OAuth security,
and this is one reason I have been looking forward to meeting
OAuthers--Torsten in particular. Whether this is going to be a formal
or informal meeting is of no real importance to me (and actually I don't
know
YES!!! (I wish I could have made this point myself as clear as George
did.)
In fact, I think this ought to be a fundamental requirement for OAuth
applicability within several domains, health services in particular.
Igor
George Fletcher wrote:
... The point of signatures is not to enable
I think Torsten's previous comment explains it well: We cannot expect
approval of the core, if security is not sufficiently addressed. I also
agree that it cannot be addressed without the signature mechanism
clearly specified. Therefore, if anything is going to delay the core, it
is the
I mistyped, and just noticed that it looked strange. I meant to type:
Igor Faynberg wrote:
...
But if both the OAuth signatures and the OAuth core specifications are
complete and going for approval at the same time, why not actually
have them in the same spec, especially given
I hope I am not causing the temperature of the group to rise dangerously
by voting in support (a.k.a. +1).
Igor
Eran Hammer-Lahav wrote:
Since much of this recent debate was done off list, I'd like to ask people
to simply express their support or objection to including a basic signature
#3/Client#3)
The difference is that the mechanism of the draft-vrancken-oauth-redelegation relies on the
temporary credentials and token credentials, which were used in OAuth 1.0,
and not on the access tokens.
Zachary
-Original Message-
From: Igor Faynberg [mailto:igor.faynb
Aaron,
Actually, I never fully understood the password access grant type, as
technically it is against the very spirit of OAuth, which, I thought,
was to avoid divulging the password.
TLS provides confidentiality, and so you ought to be able to rely on
TLS, although I have no idea what
- FI/Espoo) wrote:
I am not aware of the ITU-T terminology. Are the documents publically
available?
-Original Message-
From: ext Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Wednesday, August 11, 2010 7:31 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: OAuth WG
+1
(1) is crystal-clear and is a must, as far as I am concerned. (2) would
definitely help as a catch-all for unauthorized requests.
Igor
Torsten Lodderstedt wrote:
Would it make sense to support two scenarios? (1) Discovery as described in my original
posting independent of functional
+1 on MAY; (+0.3 on SHOULD).
Igor
Torsten Lodderstedt wrote:
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking
An important point, which I think should be captured in the security
consideration section.
Igor
Torsten Lodderstedt wrote:
what about guessing/brute force attacks on the code? Supposed an
authorization server issuing tokens for a client w/o secret. Then the
number of attempts needed to
I tend to agree with Eran, although it should be qualified that a token
is BASED on a shared secret, rather than is a shared secret itself. (By
the way, I think the word symmetric is redundant here.).
I also think that the text in the Security Considerations must contain
the last paragraph of
YES!!!
Brian, could you please add this?
Igor
Brian Eaton wrote:
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
In this case, the term capability MUST be defined up front. The word
capability seems to carry a much broader meaning than password
A good question!
I suspect I know the problem here.
In mobile networks users are authenticated separately and for separate
purposes. So, one gets authenticated via MSISDN for the link layer
connection, with IMSI--for UMTS, with IMPI--for IMS. (All of these are
achieved by using the AKA
I thought I had already written this, but I guess the e-mail never went
anywhere...
I do have a strong opinion on Torsten's proposal, and it is POSITIVE.
A nit pick: I would replace Array with List, to read A list of
access tokens issued...
Igor
Torsten Lodderstedt wrote:
no one in the
I agree. Clarity is essential, and if this is not fixed now, it will
stay like that forever.
In fact, I would define 'type=web_server_auth' for 2.5.1 and
'type=web_server_token' for 2.5.2.
Igor
Marius Scurtescu wrote:
There are two requests that have type=web_server (but they are
directed
+1
Igor
Richer, Justin P. wrote:
What I like about Brian's solution (a lot) is that you can at least see what the heck the client thought it was doing. When you're inside of a framework, your URL may get all kinds of munched up but you can usually tell if an incoming one makes sense to you in
+1 on the support.
Torsten, I just wonder if you see this as (possible a part of ) a
single-sign off method?
Igor
Torsten Lodderstedt wrote:
Hi Eran,
in my perception, there is some support on the list for having a
request to revoke refresh tokens. Will you add such a request to the
1 - 100 of 113 matches
Mail list logo
