Revocation - My assumption is that Yochi would tell Yahoo Calendar to pull
Leon's permission. This would happen out of band. When Live Calendar (Leon's
service provider) tries to use its refresh token to get an access token from
Yahoo's token endpoint the request will fail because the permission is gone. I
have thought about having a 'negative' permission flow (e.g. a notification
that a permission is no longer provided) but there are social issues with this
that make me wonder if it's viable. Think of unfriending people in Facebook.
You don't get a notification that someone has unfriended you for just that
reason.
Re-Delegation - This is one of those features that makes sense in theory but
I'm not convinced normal humans (and that includes developers) can grok. I
think we should start with 1:1 permissions for now. In other words for the
scenario you gave below Yochi would have to directly grant permission to the
3rd party service to both the Yahoo Calendar and Facebook accounts.
But that's really just my opinion,
Thanks,
Yaron
> -----Original Message-----
> From: Thomas Hardjono [mailto:hardj...@mit.edu]
> Sent: Wednesday, June 23, 2010 11:40 AM
> To: Yaron Goland; OAuth WG (oauth@ietf.org)
> Subject: RE: OAuth discovery draft?
>
>
> Hi Yaron,
>
> I think delegation is a great idea/feature that should be added or OAuth (as I
> suggested in the kerberos-oauth draft). In the Kerberos world, it has been a
> very important feature (a life saver).
>
> In your example, when Yochi wants to terminate the delegation she gave to
> Leon, how does Yochi do this?
>
> Also, would it be possible for Yochi to delegate to another system (not a
> human user) to do things for her. For example, give delegation to a 3rd party
> service/system to (a) regularly fetch Yochi's Saturday/Sunday schedule from
> Yahoo Calendar, and then (b) publish it to FaceBook say.
>
> /thomas/
>
>
> > -----Original Message-----
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Yaron Goland
> > Sent: Wednesday, June 23, 2010 2:00 PM
> > To: Eran Hammer-Lahav; Manger, James H; OAuth WG (oauth@ietf.org)
> > Subject: Re: [OAUTH-WG] OAuth discovery draft?
> >
> > I've been noodling [1] a lot about full delegation in OAuth [2] and one
> > of the issues that came out of that was the need for discovering both
> > the location and realm of an endpoint's token server. But at least for
> > my use cases (which consist of walking up to a service and making an
> > options request and getting back a www-authenticate header) all I need
> > back is a realm and a token server URL. In other words just having one
> > argument added to our www-authenticate header would be enough to
> solve
> > the case where someone wants to walk up to a service and find out where
> > its token server is. Does that really need its own spec? Or can we just
> > add an argument to www-authenticate in the current spec?
> > Thanks,
> > Yaron
> >
> > [1] See http://www.goland.org/oauthgenericdelegation/ for an overview
> > of my thinking on full delegation in OAuth. At the very end are links
> > to a bunch of other much more in-depth articles on particular subjects
> > touched on in the main article.
> >
> > [2] I define 'full delegation' as "User X of Service Y grants
> > permission Z to User A of Service B". Currently OAuth requires X == A.
> > In the future I hope to see extensions to OAuth that enable what I'm
> > terming 'full delegation'. But personally I'm really happy that OAuth
> > has the X==A restriction. It simplifies a whole host of issues and
> > satisfies a really important use case.
> >
> > > -----Original Message-----
> > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> > Behalf
> > > Of Eran Hammer-Lahav
> > > Sent: Monday, June 21, 2010 9:50 PM
> > > To: Manger, James H; OAuth WG (oauth@ietf.org)
> > > Subject: Re: [OAUTH-WG] OAuth discovery draft?
> > >
> > > Yes, it's on my desk and not yet ready, but I am working on one. It
> > > includes your sites proposal among other things. I am trying to get
> > > the core spec stable this week and focus on that next.
> > >
> > > EHL
> > >
> > > > -----Original Message-----
> > > > From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> > > > Sent: Monday, June 21, 2010 8:03 PM
> > > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> > > > Subject: OAuth discovery draft?
> > > >
> > > > Eran,
> > > >
> > > > There have been a few mentions recently of an OAuth discovery
> > draft.
> > > > Is there any such draft yet, or is this just a part that we know
> > > > needs to be done?
> > > >
> > > > The email on "OAuth meeting notes on -05 (with updates)" said:
> > > >
> > > > >> 6.1.1. - describing the WWW-Authenticate response header
> > > > >>
> > > > >> - Discovery needed for various elements
> > > > >
> > > > > Yes. That's for the discovery draft.
> > > >
> > > >
> > > > A wiki page on "Future OpenID Technical Requirements"
> > > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements>
> says:
> > > >
> > > > > 6) IdP Discovery
> > > > >
> > > > > * Much of this will be covered by OAuth2 Discovery,
> > > > > however OIC may need to define OpenID specific features.
> > > > >…
> > > > > 17) Simpler discovery
> > > > >
> > > > > * See Eran's OAuth Discovery proposal
> > > >
> > > >
> > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that
> > is tagged:
> > > > "expired", "marked as obsolete by its author", "discouraged from
> > > > implementing", "no update is expected", "replaced by the OAuth 2.0
> > > effort".
> > > >
> > > > I know I should write a discovery draft myself.
> > > >
> > > > --
> > > > James Manger
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
