tml) looks
> promising here.
>
>
>
> Kai Lehmann
>
> 1&1 Mail & Media Development & Technology GmbH
>
>
>
>
>
>
>
> *From: *OAuth on behalf
> of Warren Parad
>
> *Date: *Monday, 3. April 2023 at 00:00
> *To: *Clinton Bunch
>
Mail & Media Development & Technology GmbH
*From: *OAuth on behalf of Warren Parad
*Date: *Monday, 3. April 2023 at 00:00
*To: *Clinton Bunch
*Cc: *"oauth@ietf.org"
*Subject: *Re: [OAUTH-WG] A proposal for a new Internet Draft
I think it would make sense if after CalDAV was
;
Subject: Re: [OAUTH-WG] A proposal for a new Internet Draft
I think it would make sense if after CalDAV was updated to explicitly include
OAuth scopes relevant for it, that it could be considered to update the
official OAuth parameter scope list to include them. But I would like to avoid
doin
I think it would make sense if after CalDAV was updated to explicitly
include OAuth scopes relevant for it, that it could be considered to update
the official OAuth parameter scope list to include them. But I would like
to avoid doing this in reverse. I.e. Let's have the calendar experts decide
On 4/2/2023 4:44 PM, Warren Parad wrote:
If CalDAV is that spec, then wouldn't it make sense to request updates
to that spec to additionally define OAuth scopes? I don't think it
makes sense for the OAuth WG to define scopes for other specs, and I
also don't think updating the CalDAV spec is
If CalDAV is that spec, then wouldn't it make sense to request updates to
that spec to additionally define OAuth scopes? I don't think it makes sense
for the OAuth WG to define scopes for other specs, and I also don't think
updating the CalDAV spec is in the purview of this working group. Instead
On 4/2/2023 3:43 PM, David Waite wrote:
This seems like something more appropriate for a group focused closer to the
needs of groupware implementers (such as JMAP) to define. I would be worried
about whether we are capturing the appropriate level of complexity for these as
well as defining
Why is this still hypothetical, is there a reason you don't want to share a
concrete use case? Sure, Thunderbird needs to understand the scopes mapped
by email providers, but having shared scope names, does not imply the
implementation of those scopes. So Thunderbird still has to maintain a map
of
On 4/2/2023 3:13 PM, Warren Parad wrote:
I'm looking for proof that anyone actually needs these. Introducing
unnecessary scopes into the spec is both a waste of time and
needlessly complicates the documentation. So we need there to be a
real problem that is attempting to be solved in which
This seems like something more appropriate for a group focused closer to the
needs of groupware implementers (such as JMAP) to define. I would be worried
about whether we are capturing the appropriate level of complexity for these as
well as defining interoperable usage - for examples around
I'm looking for proof that anyone actually needs these. Introducing
unnecessary scopes into the spec is both a waste of time and needlessly
complicates the documentation. So we need there to be a real problem that
is attempting to be solved in which additional scopes is the right solution.
I'm
On 4/2/2023 2:49 PM, Warren Parad wrote:
But why these scopes?
Separate read and write scopes for the three pieces of a groupware
service seemed appropriate. And separating the three pieces of
groupware seemed appropriate as not all domains or users will use all of
them.
But since the
But why these scopes?
On Sun, Apr 2, 2023 at 9:37 PM Clinton Bunch wrote:
>
>
> On 4/2/2023 2:26 PM, Warren Parad wrote:
>
> Sorry, I'm asking why these scopes at all? I personally have never seen
> any of them used ever (and I'm not being hyperbolic), How did you come up
> with these
On 4/2/2023 2:26 PM, Warren Parad wrote:
Sorry, I'm asking why these scopes at all? I personally have never
seen any of them used ever (and I'm not being hyperbolic), How did you
come up with these suggestions?
The naming seemed logical given the IANA URI namespace. I was looking
for
Sorry, I'm asking why these scopes at all? I personally have never seen any
of them used ever (and I'm not being hyperbolic), How did you come up with
these suggestions?
On Sun, Apr 2, 2023 at 8:46 PM Clinton Bunch wrote:
> On 4/2/2023 1:34 PM, Warren Parad wrote:
>
> I propose a set of nine
On 4/2/2023 1:34 PM, Warren Parad wrote:
I propose a set of nine well-known scopes
Can you elaborate on what you mean by "well-known"? Is there some
canonical list, where these were pulled from?
I was trying to avoid the use of standard, as that implies they must be
used. To
>
> I propose a set of nine well-known scopes
Can you elaborate on what you mean by "well-known"? Is there some canonical
list, where these were pulled from?
- Warren
On Sun, Apr 2, 2023 at 8:12 PM Clinton Bunch wrote:
> This seemed the most appropriate working group to post this suggestion.
This seemed the most appropriate working group to post this suggestion.
I would like to see a new Internet-Draft/RFC to add some well-known
scopes to the IANA registry to promote adoption of Oauth in Groupware
domains. I will try to write it myself, but have no experience with
I-Ds or as a
18 matches
Mail list logo
