This topic should not have been raised again with this mailing list as we
did reach a consensus before. What happened was that Barry sent a targeted
email to some people, including Michael Thomas, regarding some additional
wording as part of his shepard review. Michael inadvertently replied to
thi
Michael Thomas wrote on 24/04/2012 14:24:47:
>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
> > Hi Thomas
> >
> > Your additional text is already covered in a countermeasure for section
&g
Hi Thomas
Your additional text is already covered in a countermeasure for section
4.1.4. In addition, section 4.1.4.4 states the assumption that the auth
server can't protect against a user installing a malicious client
Regards
Mark
oauth-boun...@ietf.org wrote on 23/04/2012 17:09:11:
> From:
Hi Peter
The core oauth spec states that TLS MUST be used wherever tokens or
passwords are being transmitted, except for the redirection_url but it does
recommend it use TLS in section 3.1.2.1 and explicitly states why.
Regards
Mark
oauth-boun...@ietf.org wrote on 22/02/2012 01:34:08:
> From:
>
think a section should be added to the security model doc.
>
> On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client
> Registration of phishing clients":
> http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html
>
> I'm happy to propose the text;
or the
user
>across applications. The user is then always presenting their
> credential to a
>known and trusted web page. Collection and use of primary
> authentication from
>the user by client applications is NOT RECOMMENDED.
>
I don't agree that your wording clar
Why do you think this William? Apple does it? Google android market had to
pull 30 apps recently because they contained malware. There are automated
tools that will do some sanity checks on apps and it is only advice, i.e.
'could'
Mark
> William Mills
>
> " o Client applications could be val
Having read the suggested wording from Eran, William and Michael, I think
Eran's description is the most succinct and relevant: "OAuth does not
provide any protection against malicious applications and that the end user
is solely responsible for the trustworthiness of any native application
install
rom:
>
> Michael Thomas
>
> To:
>
> Peter Saint-Andre
>
> Cc:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba
> , oauth WG , "oauth-
> boun...@ietf.org"
>
> Date:
>
> 04/01/2012 20:07
>
> Subject:
>
> Re: [OAUTH-WG] WGLC on dr
Hi Michael
Can you clearly word the threat for which this countermeasure (or lack of)
applies
thanks
Mark
Michael Thomas wrote on 03/01/2012 23:52:54:
> From:
>
> Michael Thomas
>
> To:
>
> Phillip Hunt
>
> Cc:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, Barry Le
Andre
You are right that the threat model does not cover this kind of issue
related to client registration. Client registration is considered to be out
of scope in the oauth spec but it is worth drawing developers attention to
this. I can add a threat entitled something like "Client Registration
Michael,
I will review the comments from Phil where he suggests some changes in
section 4.1.4 of the threat model
I am unclear exactly what you are proposing. If you want to propose a
clearly worded revamp of that section in the next couple of days, I am
willing to review and accept legitimate ch
Thanks Barry - I just responded to that thread. We will not be making any
changes to the threat model based on that comment
Regards
Mark
oauth-boun...@ietf.org wrote on 15/12/2011 14:30:02:
> From:
>
> Barry Leiba
>
> To:
>
> oauth WG
>
> Date:
>
> 15/12/2011 14:30
>
> Subject:
>
> Re: [OAUTH-
ed on that consensus, I would consider this issue
closed and we will not be making any changes to the threat model
Regards
Mark McGloin
On Wed, 26 Oct 2011 13:17:58 , "Michael Thomas" wrote:
First, I think that this threat should be elevated to something more than
a threat because it
eorigin, which will block any framing or
framing by sites with a different origin, respectively. For older browsers,
javascript framebusting techniques can be used but may not be effective in
all browsers.
Regards
Eran Hammer-Lahav wrote on 04/07/2011 20:02:02:
> From:
>
> Eran Hamm
This assumes we support the authorization code grant type without client
authentication. See
http://www.ietf.org/mail-archive/web/oauth/current/msg06816.html and many
other contributions on the same topic
Regards
Mark
oauth-boun...@ietf.org wrote on 29/06/2011 02:15:10:
> From:
>
> Anthony Nada
The question below remains unanswered in relation to native apps being able
to use grant type auth code to utilize refresh tokens. Which of these is
the best option
1) Change oauth spec so client credentials are optional when requesting
access token for grant type 'authorization_code' and for refr
"William J. Mills" wrote on 01/06/2011 00:17:44:
> From:
>
> "William J. Mills"
>
> To:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, "oauth@ietf.org"
>
> Date:
>
> 01/06/2011 00:17
>
> Subject:
>
> Re: [OAUTH-WG] Draft 16 Security Cons
the client which
MUST then validate the state parameter matches on the response.
Regards
Mark
Torsten Lodderstedt wrote on 01/06/2011 09:11:31:
> From:
>
> Torsten Lodderstedt
>
> To:
>
> Mark Mcgloin/Ireland/IBM@IBMIE
>
> Cc:
>
> oauth@ietf.org
>
> Date:
&
Eran
Here are some additional sections to add to the next draft under security
considerations
CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an a
Hi Igor, I will pass on your comments
Regards
Mark
Igor Faynberg wrote on 16/05/2011
09:45:23:
> Igor Faynberg
> 16/05/2011 09:45
>
> Please respond to
> igor.faynb...@alcatel-lucent.com
>
> To
>
> Mark Mcgloin/Ireland/IBM@IBMIE
>
> cc
>
> fcore...
Hi Igor, comments Inline below
Igor Faynberg wrote on 16/05/2011
09:02:25:
> Igor Faynberg
> 16/05/2011 09:02
>
> Please respond to
> igor.faynb...@alcatel-lucent.com
>
> To
>
> Mark Mcgloin/Ireland/IBM@IBMIE
>
> cc
>
> oauth@ietf.org
>
> Subjec
/papers/B0D33665257DD3A0852576410043BCDD/$File/rc24856.pdf
Regards
Mark
Francisco Corella wrote on 13/05/2011 17:58:01:
> Francisco Corella
> 13/05/2011 17:58
>
> Please respond to
> fcore...@pomcor.com
>
> To
>
> oauth@ietf.org, Mark Mcgloin/Ireland/IBM@IBMI
Does anyone know of a formal security protocol analysis that has been
carried out for OAuth 2.0?
I could only find analysis done against 1.0a, like this one:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5762765
thanks
Mark
___
OAuth maili
So we have 2 different communities of Oauth developers that will never
agree.
SHOULD: Typically the social networking sites that need to cater for tail
end developers by not enforcing TLS on redirect_uri. It is a risk to think
that using strong language in the spec will help them appreciate the is
Hi Marius,
Can you provide very high level details on what that approach is?
thanks
Mark
oauth-boun...@ietf.org wrote on 01/04/2011 02:34:56:
> Marius Scurtescu
> Sent by: oauth-boun...@ietf.org
>
> 01/04/2011 02:34
>
> To
>
> Greg Brockman
>
> cc
>
> oauth@ietf.org
>
> Subject
>
> Re: [OAUT
sent over TLS is still
being debated wrt redirect_uri
2.12. Authenticity of endpoints
I think I must be missing some subtleties of the statements in this section
as I don't understand. Is it just stating that both must be capable of
supporting TLS?
Mark McGloin
Torsten Lodderstedt wro
Eran, you are right about the plan. We have already had a couple of
iterations of distilling the separate document down into a security
considerations section for inclusion in the spec and will complete if based
on feedback Torsten received this week at IETF-80. I am unable to attend
Mark
oauth
ussed
before that too
thanks
Mark McGloin
oauth-boun...@ietf.org wrote on 11/03/2011 22:22:16:
> Igor Faynberg
> Sent by: oauth-boun...@ietf.org
>
> 11/03/2011 22:22
>
> Please respond to
> igor.faynb...@alcatel-lucent.com
>
> To
>
> Peter Saint-Andre
>
> cc
Marius
Isn't the risk of the refresh token leaking the same as the risk of the
access token leaking, i.e. why not provide both? IMO, the refresh token
just provides a server side mechanism for revoking access, where resource
servers are distributed, through having short lived access tokens
Of cou
gh as we just wanted to add something before China.
Based on feedback from people like Richard Barnes and Anthony Nadalin, we
intend to rework it but I just wanted to make sure I am not duplicating
effort
Regards
Mark McGloin
oauth-boun...@ietf.org wrote on 11/11/2010 11:18:52:
> Hannes Ts
needs tidying but we wanted to push something in
before the security meeting in China
Regards
Mark McGloin
oauth-boun...@ietf.org wrote on 09/11/2010 08:53:40:
> "Richard L. Barnes"
> Sent by: oauth-boun...@ietf.org
>
> 09/11/2010 08:53
>
> To
>
> tors
Eran Hammer-Lahav wrote on 29/09/2010 15:50:33:
> >
> > -1 to splitting acquiring and using a token. It may not confuse
> people actively
> > engaged in the WG but what about everyone else?
>
> We are already splitting it, by putting signatures elsewhere. Just
> because you might think bearer to
n?
I don't have concrete examples to back this up but possibilities include:
automatic granting of access token, refresh tokens, non-secure channels, ??
Regards
Mark McGloin
Dick Hardt wrote on 29/09/2010 01:08
> I am mildly concerned that breaking the spec into multiple parts makes it
harder
tions/OAuthWRAP2.0SecurityConsiderations.pdf
Regards
Mark McGloin
Dick Hardt wrote on 27/09/2010 14:30
> wrt. another comment you had about security considerations, Brian Eaton
did write up a bunch of security considerations for WRAP.
___
OAuth mailing list
OAuth@ietf.o
+1 to having it in the core spec. I don't see how an optional section in
the spec will cause any confusion
+1 to John's suggestion below of starting with the OAuth 1.0a signature
mechanism. Why not put it in the spec and see what breaks or no longer
holds true
Mark McGloin
John Pa
Hi Torsten
Yes, I can contribute. Will email you directly to follow up
Regards
Mark McGloin
Torsten Lodderstedt
14/09/2010 17:01
I plan to work on that aspect. Do you (or someone else) want to contribute?
regards,
Torsten.
Am 14.09.2010 um 17:18 schrieb Mark Mcgloin :
> What ab
What about Security Considerations. I know some individuals have worked on
it in the past - does it need a WG to complete
Mark McGloin
Hannes Tschofenig
Sent by: oauth-boun...@ietf.org
12/09/2010 00:59
Hi all,
at the Washington Internet Identity Workshop we had the chance to chat
about
ntent on using refresh tokens with
assertions intend to link the two?
Regards
Mark McGloin
On 08/07/2010 23:49 Brian Eaton wrote:
Nice summary, thanks Brian!
I think there is a third issue as well, i.e. what the use case for
client_id actually is.
I think Chuck's use case has client_
for altering the token
response is a good suggestion
Mark McGloin
> On 31/05/2010 06:58 James Manger wrote
>>... we're going to have to split out profiles to deal with the
>> different key distribution challenges.
>Instead of starting with profiles, I think a key to addr
> 1. Server Response Format
No Preference
> 2. Client Authentication (in flows)
> A. Client authenticates by sending its credentials using special
parameters (current draft)
> B. Client authenticated by using HTTP Basic (or other schemes supported
by the server such as Digest)
Prefer B
Mark
+1 to option 3
I think the suggestion below from Torsten makes great sense, especially in
relation to standardized apis such as mail
Mark
On 01 May 2010, at 13:36 PM, Eve Maier wrote:
> Am 01.05.2010 03:07, schrieb Marius Scurtescu:
>> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt
>
+1 to this
Mark McGloin
>On 16/04/2010 17:08, Richard Barnes wrote:
>Sure, this seems sensible, especially with the *optional* part.
>On Apr 15, 2010, at 3:22 PM, David Recordon wrote:
>> +1, remember discussing this a week or so ago on the list
>>
>>> On
client identifier but they only request contacts for some operation,
and the user feels more secure. Is this the main reason for scope?
James, how does your proposal work if the client needs access to more than
one set of resources?
Mark McGloin
My point though is why remove the Native app flow and then replace it with
something that relies on having to warn the user about possible phishing
attacks in your UI, like FlickR does. I would find it difficult to get that
approved here in IBM
I must look again at Luke Sheppard's suggestion for c
e device
>code on the URL. The code can be very long and impossible to
>brute-force. The session fixation/phishing attack still exists, but I
>agree that could be addressed with good UI.
What is the benefit in combining Native flow and Device flow and then
having to expend effort preventi
-hardt-oauth-01. We have strong customer use-cases for an
assertion based flow, specifically SAML bearer tokens, and I >believe
Microsoft may have already shipped a minor variation on this ( wrap_SAML )
in Azure.
Mark McGloin
___
OAuth mailing l
think the protocol should include a signature-based
authentication scheme?
Yes. I think there will be some use cases or worries from over-cautious
CIOs that it will neccessitate it.
Mark McGloin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or
48 matches
Mail list logo
