IMO, we're getting very off topic here. The WebAuthn text is not part of
the draft being called for adoption.
On Thu, Sep 5, 2024 at 2:15 AM Neil Madden wrote:
> On 5 Sep 2024, at 05:45, David Waite wrote:
> >
> >
> >
> >> On Sep 4, 2024, at 4:27 PM, Neil Madden
> wrote:
> >>
> >>> On 4 Sep
ransport/hybrid transports
Current text: "The mobile phone must support CTAP 2.2+ to be used as a
cross-device authenticator."
Proposed text: "The device serving as the FIDO authenticator must support
CTAP 2.2+ to be used as a cross-device authenticator."
tim
On Mon, Apr 22, 2024
I support working group adoption of this draft.
tim
From: OAuth on behalf of Rifaat Shekh-Yusef
Date: Wednesday, April 27, 2022 at 09:50
To: oauth
Subject: [OAUTH-WG] Call for adoption - Step-up Authentication
This is a call for adoption for the Step-up Authentication document
https
+1 in support of publication!
Tim Cappalli | @timcappalli<https://twitter.com/timcappalli>
did:ion:EiBgPHSLu66o1hQWT7ejtsV73PfrzeKphDXpgbLchRi32w
[Graphical user interface Description automatically generated with medium
confidence]
From: OAuth on behalf of Rifaat Shekh-Yusef
I support publication of JWK Thumbprint URI specification.
Tim
From: OAuth on behalf of Kristina Yasuda
Date: Thursday, February 3, 2022 at 17:48
To: Vladimir Dzhuvinov , oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
I support publication of JWK Thumbprint URI
I support adoption.
From: OAuth on behalf of Rifaat Shekh-Yusef
Sent: Thursday, January 13, 2022 09:26
To: oauth
Subject: [OAUTH-WG] Call for adoption - JWK Thumbprint URI
All,
This is a call for adoption for the JWK Thumbprint URI draft:
https://datatracker.i
e.com
Cc: Tim Cappalli ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Specifications for Identity Providers
How would that work? Would we need to work with W3C to ensure conformity of
standards?
On Mon, Aug 9, 2021, 4:11 PM mailto:mich...@palage.com>>
wrote:
Although the IETF has been invol
h
Sent: Monday, August 9, 2021 16:03
To: Tim Cappalli
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Specifications for Identity Providers
You don't often get email from kevats...@gmail.com. Learn why this is
important<http://aka.ms/LearnAboutSenderIdentification>
That's a good p
I believe this topic would be more W3C scope, not IETF.
tim
From: OAuth on behalf of Kevat Shah
Sent: Sunday, August 8, 2021 16:37
To: oauth@ietf.org
Subject: [OAUTH-WG] Specifications for Identity Providers
Some people who received this message don't
On Fri, Feb 26, 2021 at 8:10 AM Justin Richer wrote:
> Right, it’s possible to patch OAuth to do this, but the whole
> “registration equals trust” mindset is baked into OAuth at a really core
> level. That’s one of the main reasons there’s been hesitance at deploying
> dynamic registration. It’s
The OAuth work has successfully built a perfectly reasonable syntax and
protocol for exchanging identity and attribute assertions, and that's
fine. What it hasn't done is opened up the world of Identity Provision,
but that's not a technical problem.
OAuth flowed out of OpenID back in the day. Th
Here’s the OSW recording on app2app.
https://www.youtube.com/watch?v=vktyY5CXwjg
From: OAuth
Date: Tuesday, November 3, 2020 at 14:14
To: Joseph Heenan , George Fletcher
Cc: oauth
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
Thanks Joseph.
George Fletcher ran a great sessi
The original message (and calendar invite) said the 8/10 meeting was at 6am
EDT. Is it 6 or 12?
tim
From: OAuth
Date: Wednesday, July 15, 2020 at 18:05
To: oauth
Subject: [OAUTH-WG] OAuth WG Interims - Aug/Sep 2020
All,
As you might have noticed, we are starting a series of interim meetings
tasharing-terms-conditions
Hope this helps.
tim
Tim Cappalli | @timcappalli<https://www.twitter.com/timcappalli>
[Microsoft logo]
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
seful crypto agility in my experience.
>
Note that I'm proposing one alg per key ID, not one alg per issuer (sorry
in advance if I misunderstood what you meant here).
Tim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
t key
ID. This could still be exploitable in implementations that use the alg
field, since alg would still determine how the key is used.
Tim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
;t know what clients are using the play API to get 3rd party tokens.
>
> Perhaps Tim Bray can comment on scale of use if not specific clients.
>
> John B.
>
> On Mar 27, 2014, at 3:36 PM, Lewis Adam-CAL022 <
> adam.le...@motorolasolutions.com> wrote:
>
> I get the i
On Fri, Oct 25, 2013 at 1:41 PM, Phil Hunt wrote:
> Finally, I'm not sure who might be able to lead this (Tim?), but there was
> some interesting views expressed by Google staffers at this weeks IIW in
> Mountain View that seem to indicate that the need for client credentials in
. -T
On Thu, Apr 18, 2013 at 9:13 AM, Anthony Nadalin wrote:
> If I don’t specify a scope, then the server can allocate a default (or
> default set), thus that breaks the semantics you describe
>
> ** **
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *O
ding it might be useful in some contexts, I’m OK keeping it,
> provided we be clear that the semantics of “registered to use” are
> service-specific.
>
> ** **
>
> -- Mike
>
> ** **
>
> *From:* Tim Bray
> -- Mike
>
> ** **
>
> *From:* Justin Richer [mailto:jric...@mitre.org]
> *Sent:* Monday, April 15, 2013 12:29 PM
>
> *To:* Mike Jones
> *Cc:* Tim Bray; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values**
*Justin Richer
> *Sent:* Monday, April 15, 2013 8:05 AM
> *To:* Tim Bray; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>
> ** **
>
> On 04/15/2013 10:52 AM, Tim Bray wrote:
>
>
>
> I’d use the existing wording; it’s per
he AS and PR (or a higher-level protocol
> like UMA).
>
> -- Justin
>
>
> On 04/15/2013 10:13 AM, Tim Bray wrote:
>
> This, as written, has zero interoperability. I think this feature can
> really only be made useful in the case where scopes are fixed strings.
>
> -T
This, as written, has zero interoperability. I think this feature can
really only be made useful in the case where scopes are fixed strings.
-T
On Apr 15, 2013 6:54 AM, "Justin Richer" wrote:
> You are correct that the idea behind the "scope" parameter at
> registration is a constraint on auth
Speaking for myself, I have considerable concern about Turing-complete
programming languages starting to emerge inside scope strings, which I
think is probably a symptom of bad engineering. I really like the idea of
specifying the scopes you’re going to ask for at registration time, and if
that al
On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones wrote:
> Tim, as background, this came from the OpenID Connect specs, where we
> tried to consistently use the convention that the locator for any resource
> that can be retrieved from the specified location be called a URL, whereas
> an
In OAuth, we have redirect_uri not redirect_url; should this be
registration_access_uri for consistency? -T
On Wed, Feb 20, 2013 at 8:23 AM, John Bradley wrote:
> I think registration_access_url is OK.I haven't heard any better names
> yet.
>
> John B.
>
> On 2013-02-20, at 1:04 PM, Mike Jon
Not deeply acquainted with the Flickr scenario, but it occurs to me to ask:
If OAuth 1.0 is working well for them, why don’t they just keep using it?
I.e. if there’s already a good solution in place for people who require
secure authn/authz over insecure channels, why would we go the extra work
of
A DELETE is an http request that asks the server to delete something. We
probably would want to avoid writing a requirement into the standard that
the server has to comply. So you get back a 204 if it worked, a 404 if
there is no such registration, a 403 if there is but the server declines to
del
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley wrote:
> Nat and I hashed out the pro's and cons of JSON requests.
>
> If we POST or PUT a JSON object we need to be specific as there rare
> several ways to do it that may work better or worse depending on the
> receiver.
> This needs to be looked o
?! /foo and /foo/bar are obviously distinct endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" wrote:
> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
>
>> At most, there should be two endpoints - creation and management - for a
>> client, but the protocol should be structured such that they
OIDC seems about the most plausible candidate for a “good general solution”
that I’m aware of. -T
On Tue, Feb 5, 2013 at 1:22 PM, William Mills wrote:
> There are some specific design mis-matches for OAuth as an authentication
> protocol, it's not what it's designed for and there are some probl
>From the point of view of developer experience, meh, the degree of
difficulty of generating/parsing JSON & form/url is about the same.
JSON has the advantage that it forces you to use UTF-8, and is more
pleasant to debug when things get weird.
For my money, anything that forces anyone to use UTF
As I read back through this one I’m not getting why you need a new refresh
token. What am I missing? -T
On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton wrote:
> On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote:
>
>> We've had OAuth2 running successfully for a while now, but we're finding
>> th
Quick question: Why is it “association request”, not “registration
request”? Nearly everywhere the term “association” appears, it seems like
you could insert “registration” and achieve better clarity. -T
On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. wrote:
> This draft combines the best-usa
That might have happened had there been some free high-quality ASN.1
software, instead of slow buggy parsers that cost $50K to license.
It’s always seemed to me that one reason XML took off so fast is that
there were fast robust open-source parsers in C and Java before the
spec was even finalized.
this work better if I summarized the problems here inline in
this thread? It may be the pace that people’s IETF/email workflow is
such that they’re not able comfortably to consult external references?
-Tim
On Fri, Apr 20, 2012 at 7:17 AM, Derek Atkins wrote:
> Paul,
>
> "Paul E.
ts 1 & 2 you’re reacting to are from someone else. But we
agree that the choice of formats isn’t crucial. Where we disagree is
that we should pick just one, not multiple ones. -T
On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones wrote:
> Tim,
>
> I do not agree that it's harmfu
No. Supporting two different on-the-wire data formats is actively
harmful. Here are two pieces which explain why:
- mnot, this month: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
- Me, back in 2009
Pick one. -T
On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones wrote:
> Mike,
>
>> T
What is the deployment status of these two specs? Is either deployed
much at all? -T
On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org]
>> On Behalf Of Stephen Farrell
>> Sent
p://example.com/api#roles&;
oauth.rr.role=owner&
oauth.rr.role=editor&
oauth.rr.role=creator&
...
I suggest a constraint that the form/urlencoded is always utf-8 (c.f.
OpenURL KEV format NISO Z39.88-2004):
Ë => %C3%8B
And never:
Ë => %CB
I'm happy to write this
parser to my library just to get
key-value pairs that can be represented by form-urlencoded?
All the best,
Tim.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
p protect user
credentials through hard-to-crack hashes and the like, since those are
often used in more than one place, but I see no point in trying to
provide one-way integrity protection.
thanks,
tim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
led over it (hopefully with channel binding), but don't pretend
you'll be doing anyone favors by trying to provide partial integrity
protection that is ultimately ineffective. Just focus on better
authentication and key/certificate management and let TLS do the rest.
tim
I did a search.
Just the (latest?) RFC:
http://www.ietf.org/rfc/rfc2617.txt
thanks,
tim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
adapt HTTP Digest for OAuth?
That is not just rhetorical, it is a genuine question. What is HTTP
Digest missing that you need?
tim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
th? Note that it
already does allow for arbitrary encrypted blob values to be attached
to the digest... Ignoring the integration details for a minute
though, how does MAC improve on Digest from a security persepctive?
tim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
>No window will be big enough as experience shows some users have [clocks] that
>are off by more than an hour and a half.
FWIW, I have seen users with clocks a year off (not at HP). They set their
clocks wrong so they could run expired beta software.
Any requirement for synchronizing clocks
The issues around redirect_uri seem muddled to me. Here's what I know right
now:
Brian Eaton apparently said:
>This provides a defense against authorization codes which have leaked due to
>open redirectors.
I looked for "redirector" in
http://tools.ietf.org/html//draft-lodderstedt-oauth-se
e comfortable with our present code than I was before. Thanks for
the clarification.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, April 18, 2011 4:30 PM
To: Freeman, Tim; oauth@ietf.org
Subject: RE: Can you use POST to access protected resources?
I&
Section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15 gives examples
of how to access protected resources. All of the examples use GET.
Our protected resources are identified by a query, which might be a few
kilobytes. I'm concerned that this may not fit inside the length limitation o
bject "Protocol breaks if states are guessable".)
Does that belong in the security considerations?
It seems to me it belongs somewhere, unless someone can provide a reasonable
argument that it's not true.
Tim Freeman
Email: tim.free...@hp.com
Desk in Palo Alto: (650) 857-2581
The authorization server validates the client credentials, validates the
> authorization code,
> and ensures the redirection URI received matches the URI used to redirect
> the client
> in step (C). If valid, the authorization server responds with an access
> token.
Tim
What's the plan for filling in the security considerations? In the draft below
I see:
>9. Security Considerations
>
> [[ TBD ]]
Tim Freeman
Email: tim.free...@hp.com<mailto:tim.free...@hp.com>
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-75
Snipping out everything I agree with, there's only this remaining, including
some context so this email might make sense in isolation:
Tim:
> Section 2.1.1 says "If a redirection URI was registered, the authorization
> server MUST compare any redirection URI received at t
gers mean, then the protocol is insecure and the spec is broken. The
scenario for losing is below, but first I want to give credit to Torsten since
I'm basically agreeing with him:
(Beginning of the scenario where we can lose if the redirect_uri is guessable)
From: Freeman, Tim [mailto:ti
yet read. Thus, be sure not to spend much effort
skipping over redundant junk. For what it's worth, here are my notes.
Tim Freeman
Email: tim.free...@hp.com
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536
Section 1.4, Authorization Grant: They're interm
ng that gives B the right to do some
of those things, by bearer tokens, by some other means, or not at all?
Tim Freeman
Email: tim.free...@hp.com
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun.
y at the resource server site? There may be a good
>number of hops between SSL termination and the resource server.
If you don't trust SSL to do its job, you might as well drop it from the
protocol.
Tim Freeman
Email: tim.free...@hp.com<mailto:tim.free...@hp.com>
Desk in Palo Alto: (650
e control of sleepwell's computation and outputs, it's hopeless to
prevent sleepwell from allowing apneacheck to retrieve Alice's data. If all
else fails, sleepwell could access Alice's data itself and then allow
apneacheck to access the data from sleepwell.
For all I kno
er's behalf, and
then server A delegates to server C the work of accessing server B? That
appears to need A to have portable credentials it can give to C for this
specific authority. If A has a private key that it has to use in conjunction
with the credentials it has, then it can't
ULD, since it is important that we're really redirecting to the client when
we're distributing the authorization code by redirecting.
Writing the spec required thinking through these cases. It would be helpful if
the use cases were added to the spec, so people don't have to redisco
verified and is meant to be an
arbitrary unguessable identifier, so little is gained by verifying the
redirect_uri also. It is not used to construct the reply. Why is it required?
Tim Freeman
Email: tim.free...@hp.com
Desk in Palo Alto: (650) 857-2581
Home: (408)
egory/blog/oauth/
Repo: http://code.google.com/p/oauth2-php/
Thanks!
Tim Ridgely
http://www.opendining.net
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
the
source.
Blog: http://www.opendining.net/blog/oauth-2-0-php-library/
Google Code: http://code.google.com/p/oauth2-php/
Feedback welcome. Thanks!
Tim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
65 matches
Mail list logo
