ussion of use cases, requirements, and proposed solutions for
> authenticating non-human users ("bots") to Web sites intended for humans
> ("normal" Web sites). This is a follow-on from a side meeting at IETF 122.
>
> This list belongs to IETF area: WIT
>
> For additio
Hi David,
That looks fine to me.
Cheers,
> On 14 Aug 2024, at 7:14 AM, David Dong via RT
> wrote:
>
> Dear Mark (cc: oauth WG),
>
> As the designated expert for the Well-Known URIs registry, can you review the
> proposed registration in draft-ietf-oauth-resource-metad
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Reviewer: Mark Nottingham
Review result: Not Ready
# HTTPDIR review of drat-ietf-oauth-step-up-authn-challenge-13
I am an assigned HTTP directorate reviewer for draft-ietf-masque-connect-ip.
These comments were written primarily for the benefit of the ART Area
Directors. Document editors and
I thought we already had; if not, approved.
Cheers,
> On 9 Mar 2023, at 12:32 pm, Mike Jones
> wrote:
>
> Hi Mark,
> We’ve published
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-14.html, which
> incorporates the PR. Could you please approve IANA reg
Hi Mike,
Thanks. I left a comment on the PR, suggesting two small tweaks.
Cheers,
> On 8 Mar 2023, at 2:33 pm, Mike Jones
> wrote:
>
> Hi Mark,
>
> I've created the pull request
> https://github.com/danielfett/draft-dpop/pull/180 to incorporate your
> sugge
Feb 2023, at 6:12 am, David Dong via RT
> wrote:
>
> Dear Mark / Roy,
>
> We see that this document has been updated; could you please let us know if
> this is OK or if you have further comments?
>
> Thank you.
>
> https://datatracker.ietf.org/doc/draft-ietf-oau
Hi Brian,
> On 21 Jan 2023, at 5:46 am, Brian Campbell
> wrote:
>
>
> Hi Mark,
>
> Thanks for the review and feedback. I am aware of HTTP Structured Fields and
> certainly see value in it - even using it in some other work in which I'm
> involved. However,
st be a
letter. Is that always the case for a JWT?
If not, two other options:
- It could be conveyed as a String (surround with ")
- The three components could be decomposed and each conveyed separately
Cheers,
--
Mark Nottingham https://www.mnot.net/
efining new HTTP fields.
- The long line-wrapped example in Section 4.1 would benefit from RFC8792
encoding. In HTTP, a line-wrapped field like the one shown has whitespace
inserted between each line, which is problematic here.
Cheers,
> On 19 Jan 2023, at 5:30 am, David Dong via RT
Hi,
Could you take me off the cc please? Thanks.
Sent from my iPhone
> On 13 Jul 2022, at 4:18 pm, Neil Madden wrote:
>
>
>> On 12 Jul 2022, at 20:26, Michael Richardson wrote:
>>
>>
>> EXEC-SUM: /.well-known/jwks.json seems in use, but not registered
>> with IANA. I don't kno
le to nobody. In neither case are
> the people with power accountable to end users because they are not even
> customers, they are the product.
>
> What I am interested in is the extent to which Internet technologies are
> Technologies of Freedom. The question we need to ask ourselve
AB a
few times, but we haven't made much progress.
Cheers,
--
Mark Nottingham https://www.mnot.net/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
LS 1.3. Also,
>> > I'd note that we're well past WGCL for this document. But, with that said,
>> > I suppose adding some privacy considerations text on the subject is
>> > worthwhile. Would you propose some text for the WG to consider, John-Mark?
>>
1.2
> (and prior) and a noted difference of the new features in TLS 1.3. Also, I'd
> note that we're well past WGCL for this document. But, with that said, I
> suppose adding some privacy considerations text on the subject is worthwhile.
> Would you propose some text
track users. I recently
posted a blog entry about this:
https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.html
Thanks.
John-Mark Gurney
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I +1 this,
but at the same time, I'm wondering what happened with the argument that
this should be solved by Token Exchange instead of Introspect?
Cheers!
Mark
On 20/07/18 17:39, Phil Hunt wrote:
> +1 adoption
>
> I have always been concerned about clients doing introspection
be as a property for dynamically
registered clients?) but we haven't felt the urge to take that plunge
just yet. If we are be missing out on some insights there, I'd love to
hear more on that.
And thanks for those compliments, I'll pass them on my colleague who
wrote that!
Cheers,
Having the introspect endpoint support a response Content-Type of
`application/jwt` is exactly what we're doing in Curity. We actually
gave it a cool name in the process, a Phantom Token ;)
Doing things this way has proven highly useful in usecases where
customers have high throughput requirements
Please remove/unsubscribe this email address.
Thanks
Mark Warwick
Rock Solid Imports
1700 Quincy Ave Suite #102
Naperville, IL 60540
630-532-2622
www.rocksolidimports.com
- Original Message - Subject: OAuth Digest, Vol 88, Issue 81
From: oauth-requ...@ietf.org
Date
your insights,
Mark
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
eturn a token's info.
Cheers!
Mark
On 29/07/14 03:23, Justin Richer wrote:
> I think this perspective has a lot to do with your idea of OAuth's
> deployment model. You're right in that many people bundle the RS and the
> AS very tightly, but that's not alway
>
> Thoughts?
That works for my use case I think, assuming "authorization" doesn't
specifically mean "access grant" but whatever the AS takes it to mean.
--
Mark Wubben
http://novemberborn.net
http://twitter.com/novemberborn
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
to be revoked while device B keeps working. The user could also
remove the app from device A and then re-install it, which leaves the old
access grant intact and not revoked. That may be solved by tying authorizations
to specific devices, which OAuth currently does not cover. I'm al
last call for draft-ietf-oauth-revocation-03 on
> "Token Revocation". The draft is available here:
> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>
> Please send you comments to the OAuth mailing list by December 10, 2012.
>
> Thanks,
> Hannes
ly ask the list.
>
> EH
>
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Mike Jones
>> Sent: Wednesday, May 23, 2012 11:49 PM
>> To: Julian Reschke
>> Cc: Mark Nottingham; oauth@ietf.org
&g
s, Julian
>
> Hi, it would be awesome to see feedback on this (it has been mentioned during
> IETF LC multiple times).
>
>
> Best regards, Julian
> ___
> OAuth mailing list
> OAuth@ie
this email list
If everyone could avoid replying to this thread, we can resolve our
differences with the smaller mail group
thanks
Mark
oauth-boun...@ietf.org wrote on 24/04/2012 19:05:55:
> From:
>
> Eran Hammer
>
> To:
>
> Peter Saint-Andre
>
> Cc:
>
> "o
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:
&
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:
> F
> protected from disclosure in storage and in transport.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/dra
lient application handles user
authentication in an appropriate way
Regards
Mark
André DeMarre wrote on 16/01/2012 23:20:02:
>
> To:
>
> Eran Hammer 16/01/2012 23:22
>
>
> Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
>
> Eran,
>
> Yes; I
those will be applicable to all developers
Regards
Mark
William Mills wrote on 05/01/2012 16:29:02:
>
> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
>
> There's going to be a whole class of apps tat will be in violation
> of "Client applicati
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 Clie
that the client application handles user
authentication in an appropriate way
3. Client developers should not write client applications that collect
authentication information directly from users and should instead delegate
this task to a trusted system component, e.g. the system-browser.
Regards
M
Hi Michael
I have asked you to clearly describe the threat, not the mitigation.
It obviously was either not clear or convincing the first time and I am not
going to start digging through emails when you clearly understand it.
Regards
Mark
Michael Thomas wrote on 04/01/2012 20:05:21:
> F
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
Hi Mike,
On 18/12/2011, at 8:00 PM, Mike Jones wrote:
> Thanks for your comments, Mark. Here are my thoughts on the issues that you
> see as being outstanding. I'd also welcome additional input from the working
> group on these topics:
>
> ON THE URI QUERY PARAMETER M
lient Registration of
phishing clients". It kind of reminds me of the issues android market place
has seen recently with malware apps due to no vetting of those apps.
It is touched upon in the oauth 2 rfc:
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-2
Regards
Mark
On 3 Nov 2011 17:09:
changes. Clearly worded means
concise, technically accurate and devoid of alarmist phrases and words used
out of context, such as existential. Can I suggest you review with a
colleague before posting here.
Regards
Mark
oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45:
> From:
>
> Micha
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
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
, see some specifics
below.
Regards,
On 15/12/2011, at 1:13 PM, Mike Jones wrote:
> Mark, Stephen, Hannes, and Barry,
>
> Any objections to posting the updated Bearer draft incorporating the results
> of the APPS Area review an
It sounds like it's specifying *almost* the same thing, but in a different way.
Why is there friction? Is it fashion, NIH or something more substantial?
Cheers,
On 20/11/2011, at 4:08 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Ma
nable
multiple different encodings, nor multiple encodings with a single header.
Further, I wonder how widespread support for it is in various HTTP
frameworks.
- Mark
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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:
>
>
#x27;s redirect-uri, would that suffice?
Regards
Mark
oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22:
> From:
>
> Shane B Weeden
>
> To:
>
> oauth@ietf.org
>
> Date:
>
> 23/05/2011 06:26
>
> Subject:
>
> [OAUTH-WG] Draft 16 comment
>
> S
___
> apps-discuss mailing list
> apps-disc...@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
--
Mark Nottingham http://www.mnot.net/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On 03/06/2011, at 1:44 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Mark Nottingham [mailto:m...@mnot.net]
>> Sent: Wednesday, June 01, 2011 5:16 PM
>> To: Eran Hammer-Lahav
>> Cc: apps-disc...@ietf.org; Ben Adida; http-st...@i
am has put
into limiting the use of sniffing.
Cheers,
--
Mark Nottingham http://www.mnot.net/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated _(e.g., via HTTP redirects or HTML forms)_. CSRF attacks on
OAuth approvals can allow an attacker to obtain authorization to OAuth
Protected Resources without the consent of the User.
Regards
Mark
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:
&
y appreciated.
>
> EHL
> ___
> apps-discuss mailing list
> apps-disc...@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
--
Mark Nottingham http://www.mnot.net/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
amebusting techniques can be used but may not be effective in
all browsers.
Regards
Mark
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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
___
O
if it's
part of a bigger spec, it's inseparable.
> If you answered no to #1:
>
> 4. Should the Bearer draft retain the attribute and registry for its own
> scheme-specific needs?
Not sure how that's relevant here...
Cheers,
--
Mark Nottingham http://www.mnot.net/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
h mandates the use of TLS.
This won't break anyone using the current grant type = 'code' and providers
can choose which to support.
Mark
oauth-boun...@ietf.org wrote on 01/04/2011 01:09:46:
> Eran Hammer-Lahav
> Sent by: oauth-boun...@ietf.org
>
> 01/04/2011 01:09
&g
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
>
&g
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
>> 3. I believe that section 5.2 is ambiguous as to the error code that should
>> be
>> returned from the token endpoint when the client credentials are valid,
>> when the client is authorized to use the authorization code grant type in
>> general, but when the authorization code supplied is not va
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
token formats are
provided in companion specifications, I see no references for authorization
codes. Any thoughts on this would be gratefully received.
Mark.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
s
Of course, the refresh access token flow currently requires a secret so
would need to be changed or alternative flow introduced. Will wait for
details of how auth code flow can be used
Mark
e-mail: mark.mcgl...@ie.ibm.com
oauth-boun...@ietf.org wrote on 16/02/2011 21:38:45:
> Marius S
appear to be referenced elsewhere in the
document, and it¹s not clear to me what association is intended, or when it
should be established. A cursory search of the archives of this list has not
provided a conclusive explanation; my apologies if I¹ve missed something.
Thanks,
Mark
proposes a solution, and a corrected ABNF grammar.
I can resend if people would like.
- Mark Lentczner
mz...@google.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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
..
oauth2-key = "oauth2_" oauth2-param
oauth2-param = "access_token"
future-key = token
Lastly, if there was significant compatability issues with introducing
a new prefix to key values in OAuth credentials, then "oauth_" could
be used as the pre
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
How fortuitous:
http://blogs.msdn.com/b/ieinternals/archive/2010/08/19/http-error-pages-in-internet-explorer.aspx
On 19/08/2010, at 8:47 AM, Mark Nottingham wrote:
> See:
> http://support.microsoft.com/kb/294807
>
>
> On 19/08/2010, at 1:55 AM, Brian Eaton wrote:
>
See:
http://support.microsoft.com/kb/294807
On 19/08/2010, at 1:55 AM, Brian Eaton wrote:
> On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham wrote:
>>> The other reason people get funny with these status codes has to do
>>> with browser behavior. Sometimes browsers r
that
> says, more or less, "Whoa. That sucked."
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Mark Nottingham http://www.mnot.net/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ion about the current user."
>>>>>> }.
>>>>>> 400,
>>>>>> 'Bad Request');
>>>>>>
>>>>>> which you can grab with
>>>>>>
>>>>>> function jso
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)
Pr
+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 Lo
+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
n for combining Native app
flow with UA flow as that seems a better solution
Mark
On 15/04/2010 18:15, Marius Scurtescu wrote:
>> What is the benefit in combining Native flow and Device flow and then
>> having to expend effort preventing any ingenious phishing attacks?
>The main i
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
94 matches
Mail list logo
