Re: [OAUTH-WG] OAuth implementation fail
It seems that they don't ask for scopes. The parameter is left blank: scope= Kind regards, Maciej On 22 July 2015 at 10:26, Phil Hunt wrote: > Do they explicitly ask for those scopes? Or do they leave scope to default > that way. > > Phil > > On Jul 22, 2015, at 10:22, Justin Richer wrote: > > This is a pretty clear case of SlideShare trying to grab too much. The > LinkedIn API (which is their own proprietary thing, not OpenID Connect) > does separate all the permissions into different scopes. However, the > SlideShare app is asking for all of them, and LinkedIn doesn’t let you > uncheck any boxes on the authorization screen. > > FWIW, the reason they want write access to your profile is to > automatically add new SlideShare presentations that you upload to your > LinkedIn profile page. You should still have the option of turning that > off, or of turning on that functionality later. > > — Justin > > On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < > kathleen.moriarty.i...@gmail.com> wrote: > > Hey Barry, > > From my observations with Facebook, it now has options added for you to > select what resources from Facebook will get shared when authorizing access > to other applications. You can click on each of the possibilities and > strip it down. It appears to me that Facebook is managing that, so in your > case, I *think* (and am open to be corrected) that LinkedIn needs to do > something similar. Without those options, I also cancel out and just don't > use the other app. > > Thanks, > Kathleen > > On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba > wrote: > >> Yesterday, someone sent me a link to some presentation slides that >> he'd posted to SlideShare. I looked at them, and wanted to download >> them as a PDF. In order to let me do that, SlideShare wants me to log >> in. It gives me the options to log in via LinkedIn or Facebook. As >> I'm one of the three people in the world without a Facebook account, I >> clicked "LinkedIn". That got me an OAuth authorization screen, image >> attached. >> >> Now, I don't know if this is SlideShare's fault for asking for too >> much, or LinkedIn's fault for not providing enough granularity for >> requests, but just LOOK at that list of what I'd be giving SlideShare >> access to. The first few make sense: read my profile (the whole thing >> or pieces of it, including contact information). But... access to my >> connections? I'm not sure they'd like my exposing their identities to >> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >> >> Of course, this isn't the fault of the OAuth protocol, really (though >> one might argue that there's not enough guidance provided). But, >> really, with implementations like this, I have to wonder what they're >> thinking. >> >> I clicked "Cancel", of course, and asked the slide creator to send me a >> PDF. >> >> Barry >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > > Best regards, > Kathleen > _______ > 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 > > -- Maciej Machulak email: maciej.machu...@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?
+1 -- Cheers, Maciej (sent from my tablet) On Sep 11, 2014 5:07 PM, "Phil Hunt" wrote: > +1. Experimental seems best here. > > Phil > > > On Sep 11, 2014, at 9:03, "Richer, Justin P." wrote: > > > > +1 > > > > That was the key line that I took from the guidelines as well and this > was my understanding of the discussion in Toronto. > > > > -- Justin > > > >> On Sep 11, 2014, at 12:02 PM, John Bradley wrote: > >> > >> I think this fits. > >> > >>• If the IETF may publish something based on this on the standards > track once we know how well this one works, it's Experimental. This is the > typical case of not being able to decide which protocol is "better" before > we have experience of dealing with them from a stable specification. Case > in point: "PGM Reliable Transport Protocol Specification" (RFC 3208) > >> > >> If we publish something it may or may not look like the current spec > but getting some experience with the current spec will inform that decision. > >> > >> John B. > >>> On Sep 11, 2014, at 12:55 PM, Phil Hunt wrote: > >>> > >>> Interesting. The definitions in that don't correspond with what ADs > and other groups are doing. > >>> > >>> I heard httpbis using experimental as a placeholder for a draft that > didn't have full consensus to bring back later. > >>> > >>> That was the feel I had in Toronto-that we weren't done but it was > time to publish something. > >>> > >>> Reading the actual definition i would say neither fits. Ugh. > >>> > >>> Phil > >>> > On Sep 11, 2014, at 8:01, "Richer, Justin P." > wrote: > > According to the guidelines here: > > https://www.ietf.org/iesg/informational-vs-experimental.html > > And the discussion in Toronto, it's clearly experimental. > > -- Justin > > > On Sep 11, 2014, at 10:36 AM, Anthony Nadalin > wrote: > > > > Is "experimental" the correct classification? Maybe "informational" > is more appropriate as both of these were discussed. > > > > -Original Message- > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes > Tschofenig > > Sent: Wednesday, September 10, 2014 4:50 PM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: > Next Steps? > > > > Hi all, > > > > in response to the discussions at the last IETF meeting the authors > of the "Dynamic Client Registration Management Protocol" > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 > have changed the document type to "Experimental". > > > > We need to make a decision about the next steps for the document and > we see the following options: > > > > a) Publish it as an experimental RFC > > > > b) Remove it from the working group and ask an AD to shepherd it > > > > c) Remove it from the working group and let the authors publish it > via the independent submission track. > > > > In any case it would be nice to let folks play around with it and > then, after some time, come back to determine whether there is enough > interest to produce a standard. > > > > Please let us know what you think! > > > > Ciao > > Hannes & Derek > > > > > > > > ___ > > 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 > > > > ___ > 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
Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
gt; >>> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote: > >>>> Thanks, Mike. > >>>> > >>>> This is a useful addition and reflects the relationship between the > >>>> two efforts. > >>>> > >>>> Please add it to the next draft version. > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> On 07/15/2014 09:46 PM, Mike Jones wrote: > >>>>> So that the working group has concrete language to consider, > >>>>> propose the following language to the OAuth Dynamic Client > Registration specification: > >>>>> > >>>>> > >>>>> > >>>>> Portions of this specification are derived from the OpenID Connect > >>>>> Dynamic Registration [OpenID.Registration] specification. This > >>>>> was done so that implementations of this specification and OpenID > >>>>> Connect Dynamic Registration can be compatible with one another. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Mike > >>>>> > >>>>> > >>>>> > >>>>> *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Mike > >>>>> Jones > >>>>> *Sent:* Tuesday, July 08, 2014 7:15 PM > >>>>> *To:* Phil Hunt; Hannes Tschofenig > >>>>> *Cc:* Maciej Machulak; oauth@ietf.org > >>>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR > >>>>> Confirmation > >>>>> > >>>>> > >>>>> > >>>>> Thinking about this some more, there is one IPR issue that we need > >>>>> to address before publication. This specification is a derivative > >>>>> work from the OpenID Connect Dynamic Registration specification > >>>>> http://openid.net/specs/openid-connect-registration-1_0.html. > >>>>> Large portions of the text were copied wholesale from that spec to > >>>>> this one, so that the two would be compatible. (This is good > >>>>> thing – not a bad > >>>>> thing.) > >>>>> > >>>>> > >>>>> > >>>>> This is easy to address from an IPR perspective – simply > >>>>> acknowledge that this spec is a derivative work and provide proper > >>>>> attribution. The OpenID copyright in the spec at > >>>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notic > >>>>> e s allows for this resolution. It says: > >>>>> > >>>>> > >>>>> > >>>>> Copyright (c) 2014 The OpenID Foundation. > >>>>> > >>>>> The OpenID Foundation (OIDF) grants to any Contributor, developer, > >>>>> implementer, or other interested party a non-exclusive, royalty > >>>>> free, worldwide copyright license to reproduce, prepare derivative > >>>>> works from, distribute, perform and display, this Implementers > >>>>> Draft or Final Specification solely for the purposes of (i) > >>>>> developing specifications, and (ii) implementing Implementers > >>>>> Drafts and Final Specifications based on such documents, provided > >>>>> that attribution be made to the OIDF as the source of the > >>>>> material, but that such attribution does not indicate an endorsement > by the OIDF. > >>>>> > >>>>> Let’s add the reference and acknowledgment in the next version. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Mike > >>>>> > >>>>> > >>>>> > >>>>> *From:*Mike Jones > >>>>> *Sent:* Tuesday, July 08, 2014 10:06 AM > >>>>> *To:* Phil Hunt; Hannes Tschofenig > >>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org > >>>>> <mailto:oauth@ietf.org> > >>>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation > >>>>> > >>>>> > >>>>> > >>>>> I likewise do not hold any IPR on these specs. > >>>>> > >>>>> -- > >>>>> - > >>>>> - > >>>>> > >>>>> *From: *Phil Hunt <mailto:phil.h...@oracle.com> > >>>>> *Sent: *7/8/2014 9:11 AM > >>>>> *To: *Hannes Tschofenig <mailto:hannes.tschofe...@gmx.net> > >>>>> *Cc: *Mike Jones <mailto:michael.jo...@microsoft.com>; John > >>>>> Bradley <mailto:ve7...@ve7jtb.com>; Justin Richer > >>>>> <mailto:jric...@mitre.org>; Maciej Machulak > >>>>> <mailto:m.p.machu...@ncl.ac.uk>; oauth@ietf.org > >>>>> <mailto:oauth@ietf.org> > >>>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation > >>>>> > >>>>> I confirm I have no IPR disclosures on this document. > >>>>> > >>>>> Phil > >>>>> > >>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig < > hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>> wrote: > >>>>>> > >>>>>> Hi Phil, John, Maciej, Justin, Mike, > >>>>>> > >>>>>> I am working on the shepherd writeup for the dynamic client > >>>>>> registration document and one item in the template requires me to > >>>>>> indicate whether each document author has confirmed that any and > >>>>>> all appropriate IPR disclosures required for full conformance > >>>>>> with the provisions of BCP 78 and BCP 79 have already been filed. > >>>>>> > >>>>>> Could you please confirm? > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> > >>>> ___ > >>>> 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 > -- Maciej Machulak email: maciej.machu...@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
Hi, Yes, I agree - I think the note should mention UMA. As Justin proposed, there should be a normative reference to an IETF document. Kind regards, Maciej On 16 July 2014 13:44, Hannes Tschofenig wrote: > Interesting background information. Maybe we should then extend the note > Mike provided to also clarify the relationship with the UMA work (both > in terms to IPR, copyright, and attribution-wise). > It would also make sense to state the relationship in the introduction > to highlight the compatibility, which I believe is a big accomplishment. > > Ciao > Hannes > > On 07/16/2014 01:41 PM, Justin Richer wrote: > > I thought I had sent this note already, but I don't see it in the > > archives or in my 'sent' folder: > > > > If we're going to point to OpenID Connect (which I'm fine with), then we > > should clarify that portions were also taken from the UMA specification. > > In fact, draft -00 actually *was* the UMA specification text entirely. > > This is also what the OpenID Connect registration specification was > > (loosely) based on when it was started. > > > > In reality, the relationship between these three documents from three > > different SBO's is more complicated: they all grew up together and > > effectively merged to become wire-compatible with each other. There were > > a number of changes that were discussed here in the IETF that OpenID > > Connect adopted, and a number of changes that were discussed at OIDF > > that were adopted here. OIDC also extends the IETF draft with a set of > > OIDC-specific metadata fields and editorial language that makes it fit > > more closely in the OIDC landscape, but make no mistake: they're the > > same protocol. In the case of UMA, it's a straight normative reference > > to the IETF document now because we were able to incorporate those use > > cases and parameters directly. > > > > The trouble is, I'm not sure how to concisely state that all that in the > > draft text, but it's not as simple as "we copied OpenID", which is what > > the text below seems to say. > > > > -- Justin > > > > On 7/16/2014 6:17 AM, Hannes Tschofenig wrote: > >> Thanks, Mike. > >> > >> This is a useful addition and reflects the relationship between the two > >> efforts. > >> > >> Please add it to the next draft version. > >> > >> Ciao > >> Hannes > >> > >> On 07/15/2014 09:46 PM, Mike Jones wrote: > >>> So that the working group has concrete language to consider, propose > the > >>> following language to the OAuth Dynamic Client Registration > specification: > >>> > >>> > >>> > >>> Portions of this specification are derived from the OpenID Connect > >>> Dynamic Registration [OpenID.Registration] specification. This was > done > >>> so that implementations of this specification and OpenID Connect > Dynamic > >>> Registration can be compatible with one another. > >>> > >>> > >>> > >>> -- Mike > >>> > >>> > >>> > >>> *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Mike Jones > >>> *Sent:* Tuesday, July 08, 2014 7:15 PM > >>> *To:* Phil Hunt; Hannes Tschofenig > >>> *Cc:* Maciej Machulak; oauth@ietf.org > >>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation > >>> > >>> > >>> > >>> Thinking about this some more, there is one IPR issue that we need to > >>> address before publication. This specification is a derivative work > >>> from the OpenID Connect Dynamic Registration specification > >>> http://openid.net/specs/openid-connect-registration-1_0.html. Large > >>> portions of the text were copied wholesale from that spec to this one, > >>> so that the two would be compatible. (This is good thing – not a bad > >>> thing.) > >>> > >>> > >>> > >>> This is easy to address from an IPR perspective – simply acknowledge > >>> that this spec is a derivative work and provide proper attribution. > The > >>> OpenID copyright in the spec at > >>> http://openid.net/specs/openid-connect-registration-1_0.html#Notices > >>> allows for this resolution. It says: > >>> > >>> > >>> > >>> Copyright (c) 2014 The OpenID Foundati
Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
Hi, My apologies for a late reply. Same here, no IPR disclosures to make regarding these documents. Kind regards, Maciej On 8 July 2014 19:06, Mike Jones wrote: > I likewise do not hold any IPR on these specs. > -- > From: Phil Hunt > Sent: 7/8/2014 9:11 AM > > To: Hannes Tschofenig > Cc: Mike Jones ; John Bradley > ; Justin Richer ; Maciej Machulak > ; oauth@ietf.org > Subject: Re: Dynamic Client Registration: IPR Confirmation > > I confirm I have no IPR disclosures on this document. > > Phil > > > On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote: > > > > Hi Phil, John, Maciej, Justin, Mike, > > > > I am working on the shepherd writeup for the dynamic client registration > > document and one item in the template requires me to indicate whether > > each document author has confirmed that any and all appropriate IPR > > disclosures required for full conformance with the provisions of BCP 78 > > and BCP 79 have already been filed. > > > > Could you please confirm? > > > > Ciao > > Hannes > > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Maciej Machulak email: maciej.machu...@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Reg. - Possible Future Conference Calls
16th is perfectly fine. I will be travelling on the 22nd and I will not available. Cheers, Maciej On 3 July 2013 19:20, Justin Richer wrote: > Those times are fine for me as well. > > -- Justin > > > On 07/02/2013 02:51 PM, Hannes Tschofenig wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Hi all, >> >> I looked at the poll and I would like to reserve these additional >> conference call slots: >> >> * Tue 16, 1pm EDT >> * Mon 22, 1pm EDT >> >> Ciao >> Hannes >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iQEcBAEBCgAGBQJR0yFLAAoJEGhJUR**NOOiAtTuwH/RzYc3AoVvFatf9+**PuCAJvsZ >> FpuBSnOSFwkpeja6iWfZO9hFLzlLQK**mVeHB5MC86rNWIseFZ8lotB18cvv5V**WhKj >> qVJzQPtOdi3YCPEDLwD9gr8bgOFb0N**8AK5OUjxlxWVGnXsy54LjRutD/**MTIDDGqk >> vaicWZbeaqhct7E2FAUAdOKF3rUlGS**1IZN7+Qa3LIc8VXwyG+LS/**PRFJBxWgINQO >> TCNTrvrNcaAsG/**0cB33UddqD9Jp1MdAO/**0rbAgLRuphP4dmJrb/Uhg/**VhHIwatDC >> icQJrL1dQLRtaxRyKPge/**KS0Vkc0S8aCYkqHw01Fd/**kI9Uk5cHm4rB49IZuzNYo= >> =cyYB >> -END PGP SIGNATURE- >> __**_ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> >> > > __**_ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> > -- Maciej Machulak email: maciej.machu...@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2.0 Python Implementation
Hi, For those interested, there's a new OAuth 2.0 implementation in Python available at: https://bitbucket.org/smartproject/oauth2python Documentation for this library is available at: https://bitbucket.org/smartproject/oauth2python/wiki/Home The library has been developed entirely by Jacek Szpot (with a little help from the SMART team) who joined us recently at Newcastle University. Cheers, Maciej -- Maciej Machulak email: maciej.machu...@gmail.com tel: +44 7999 606 767 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
These are not only client libraries, they work for AS and RS too. Cheers, Maciej On 24 June 2011 18:16, Eran Hammer-Lahav wrote: > On the subject of OAuth 2.0 libraries... > > Why would you need a library?? Seems to be much less work to just make the > HTTP requests directly. And if you are using MAC, you need a MAC library, not > an OAuth 2.0... > > EHL > >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of David Recordon >> Sent: Friday, June 24, 2011 10:07 AM >> To: Eve Maler >> Cc: oauth WG >> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source? >> >> I was trying to keep http://wiki.oauth.net/w/page/25236487/OAuth-2 up to >> date but haven't in awhile. >> >> >> On Fri, Jun 24, 2011 at 10:02 AM, Eve Maler wrote: >> > Zero response from the other list. Any suggestions from folks here? >> > >> > Begin forwarded message: >> > >> >> From: Eve Maler >> >> Date: 20 June 2011 4:54:56 PM PDT >> >> To: oa...@googlegroups.com >> >> Subject: [oauth] Good list of OAuth open source? >> >> Reply-To: oa...@googlegroups.com >> >> >> >> The list at http://oauth.net/code/ seems really random and out of date. >> Does anyone have a current list of open-source software that supports >> OAuth, including drafts of 2.0? >> >> >> >> Thanks, >> >> >> >> Eve >> > >> > >> > Eve Maler http://www.xmlgrrl.com/blog >> > +1 425 345 6756 http://www.twitter.com/xmlgrrl >> > >> > ___ >> > 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 > -- Maciej Machulak email: maciej.machu...@gmail.com tel: +48 602 45 31 44 tel: +44 7999 606 767 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
I haven't seen such a list but it would be great to update the existing one on oauth.net. There's the Apache Amber project [1] which is the OAuth 2.0 implementation in Java used quite a lot. Could anyone include it in the list, please? Thank you in advance. Cheers, Maciej [1] http://incubator.apache.org/projects/amber.html On 24 June 2011 18:02, Eve Maler wrote: > Zero response from the other list. Any suggestions from folks here? > > Begin forwarded message: > >> From: Eve Maler >> Date: 20 June 2011 4:54:56 PM PDT >> To: oa...@googlegroups.com >> Subject: [oauth] Good list of OAuth open source? >> Reply-To: oa...@googlegroups.com >> >> The list at http://oauth.net/code/ seems really random and out of date. Does >> anyone have a current list of open-source software that supports OAuth, >> including drafts of 2.0? >> >> Thanks, >> >> Eve > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > _______ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Maciej Machulak email: maciej.machu...@gmail.com tel: +48 602 45 31 44 tel: +44 7999 606 767 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth leeloo V0.1
Hi, We're pleased to announce the release of a new OAuth V2.0 library - OAuth leeloo V0.1. It implements draft 10 of the OAuth spec. It allows to easily build Clients, Authorization Servers and Resource Servers. We've been using leeloo internally at one of our Web applications and as a part of a bigger framework - UMA/j (User-Managed Access Java framework). Soon we'll make publicly available our OAuth-compliant Web application that also supports site-meta/host-meta and the OAuth Dynamic Client Registration draft (as well as UMA). OAuth leeloo is available in Maven Central so you can start using it straight away :-) Check out http://leeloo.smartam.net for more information. The official blog post: http://smartjisc.wordpress.com Cheers, Maciej & Lukasz -- Maciej Machulak email: maciej.machu...@gmail.com tel: +44 7999 606 767 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] UMA Lexicon
Hi, In order to provide some input to the discussion for a clear and consistent OAuth terminology, I'm sending the terminology used in User-Managed Access (UMA). A more detailed description can be found at: http://kantarainitiative.org/confluence/display/uma/Lexicon Authorizing User: A web user who configures an Authorization Manager with policies that control how it makes access decisions when a Requester attempts to access a Protected Resource at a Host. Authorization Manager (AM): An UMA-defined variant of a WRAP Authorization Server that carries out an Authorizing User's policies governing access to a Protected Resource. Protected Resource: A resource (at a Host) whose access is restricted. (Note that this differs from WRAP's definition of the same term.) Host: An UMA-defined variant of, respectively, a WRAP Protected Resource and WRAP Client, that enforces access to the Protected Resources it hosts, as decided by an Authorization Manager. Token Validation URL: The URL at an Authorization Manager that a Host uses to validate an access token. Claim: A statement (in the sense of [IDCclaim]). Claims are conveyed by a Requester on behalf of a Requesting Party to an Authorization Manager in an attempt to satisfy user policy. (Protected Resources may also contain Claims, but this is outside the view of the UMA protocol.) Requester: An UMA-defined variant of a WRAP Client that seeks access to a Protected Resource. Requesting Party: A web user, or a corporation (or other legal person), that uses a Requester to seek access to a Protected Resource. Cheers, Maciej -- Maciej Machulak PhD Student, Newcastle University http://www.trust-economics.org/maciejm ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
