Regarding your “higher importance” comment on Section 1.1 about the
impersonation semantic below:
Eve Maler (sent from my iPad) | cell +1 425 345 6756
> On Jul 18, 2019, at 4:06 PM, Barry Leiba via Datatracker
> wrote:
>
> Barry Leiba has entered the following ballot position
://kantarainitiative.org/confluence/display/uma/UMA+Implementations
[2] https://tools.ietf.org/html/draft-maler-oauth-umagrant
[3] https://tools.ietf.org/html/draft-maler-oauth-umafedauthz
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_
cp190 <https://tools.ietf.org/html/bcp190>, but
> I think it's a good source of inspiration)
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl |
Calendar: xmlg...@gmail.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
e
>>>> identifier and get back something that lets you, the RS, check the
>>>> signature.
>>>>
>>>> -- Justin
>>>>
>>>> On Dec 2, 2014, at 1:40 PM, Bill Mills >>> <mailto:wmills_92...@yahoo.com>> wrote:
>>>>
>>>>> "However, I think it's very clear how PoP tokens
PP). Maybe you want to say that (in addition to the
> assumed relationship between the two entities). If there is no
> relationship between the two parties then they will certainly be a
> challenge to get this done securely.
Eve Maler http://www.xmlgrrl.com/blog
gt;> Hi all,
>>>>
>>>> during the IETF #90 OAuth WG meeting, there was strong consensus in
>>>> adopting the "OAuth Token Introspection"
>>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
>>>> work item.
>>>>
>>>> We would
gt;>> comments along to the list in your response to this Call for Adoption.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes & Derek
>>>>>>
>>>>>>
>>>>>> ___
f
> you have issues/edits/comments on the document, please send these
> comments along to the list in your response to this Call for Adoption.
>
> Ciao
> Hannes & Derek
>
> ___
> OAuth mailing list
> OAuth@ietf.org
&
[1] http://keycloak.org
> [2] http://tools.ietf.org/html/__rfc6750
> <http://tools.ietf.org/html/rfc6750>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ___
> OA
o do soon). We have to restart the WGLC due to discussions last
> years and the resulting changes to these documents.
>
> Ciao
> Hannes & Derek
>
> PS: Derek and I also think that Phil should become co-auhor of these
> documents for his contributions.
>
&
t provided? you'd
> have *more* information returned? I understand that this is just a framework
> and each server would have its own rules, but you're then either saying too
> much or too few.
>
> Thanks in advance for any guidance about how to achieve my
his does
>> increase the optionality by making the client configuration endpoint
>> parameters optional, but that's the tradeoff for having things cut this way.
>>
>> You can read both the specs here:
>>
>> http://tools.ietf.org/html/draft-richer-oaut
her topics you would like to bring
>>>>>> up?
>>>>>> - -BEGIN PGP SIGNATURE-
>>>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>>>>>> Comment: GPGTools - http://gpgtools.org
>>>>>>
>>>>>> i
...@oracle.com
>> On 2013-05-21, at 10:52 AM, Mike Jones wrote:
>>
>> No information is being thrown away. Developers can use dynamic
>> registration to obtain a client_id and then have all the client instances
>> use that client_id if they choose - just
most likely one.
>> > Using scope requires a relatively tight binding between the RS and AS,
>> > UMA uses a different mechanism that describes finer grained operations.
>> > The AS may include roles, user, or other more abstract claims that the the
>
tus:
>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-
simple solution may be to allow the client to register
> via the dynamic registration proposal the token types it supports and then
> the AS can use that data as a filtering mechanism when the client asks for a
> token.
>
> Thanks,
> George
>
> On 1/23/13 12:23 PM, Eve Maler
odd W Lainhart wrote:
>
>> > On the other hand, it's a useful exercise to imagine how much more benefit
>> > could potentially be gotten "for free" if we look at it through a
>> > pure-REST lens, not just with what's already been specified but the w
Rudely responding to myself: I'm not saying this approach should definitely be
taken, just that it's a good idea to spend 15 minutes looking at the benefits
and downsides of it vs. the current laser-focus approach.
Eve
On 23 Jan 2013, at 9:28 AM, Eve Maler wrote:
>
ration (wording to be determine) OPTIONAL inquire (default) | revoke
>>>>> ...
>>>>> resource_idOPTIONAL
>>>>> client_id OPTIONAL
>>>>> client_secret
t; OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
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
d like to recommend is to add "action"/"operation" to the
>>>>> request. (and potentially add client_id and client_secret)
>>>>>
>>>>> So the request will be like :
>>>>> token
On 28 Dec 2012, at 5:58 AM, "Anganes, Amanda L" wrote:
> Hi Eve and Thomas,
>
> On 12/27/12 8:11 PM, "Eve Maler" wrote:
>
>> Amanda, thanks for the lightning-fast comments back. A couple of additional
>> notes on top of Thomas's response:
&g
oauth-resource-reg
>>> Revision: 00
>>> Title: OAuth 2.0 Resource Set Registration
>>> Creation date: 2012-12-27
>>> WG ID: Individual Submission
>>> Number of pages: 19
>>> URL:
>>> http://www.ietf.org/internet
> > > token service.
> > > > Conceptually, it could be any token service (functionality)
> > > residingin any of
> > > >
> > > > the stakeholders (Resource Owner, OAuth Client, Authorization Server,
> > > > or
> > > >
nfo that would come back from such a token introspection would be,
> and what it means. Different types of tokens (Bearer, MAC, HOK) are going to
> have different types of metadata associated with them, probably, but there
> are a few core pieces (expiration, scopes) that would be common
s.ietf.org/html/draft-richer-oauth-introspection-00
>>
>>
>> Abstract:
>> This specification defines a method for a client or protected
>> resource to query an OAuth authorization server to determine meta-
>> information about an OAuth token.
>>
>>
>>
>>
>>
>> The IETF Secre
ch simpler.
>
> But even so, I think the simple case of "I have a token and want to know
> about it" needs to be supported without extra scaffolding.
>
> -- Justin
>
\
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756
nspecified or omitted" redundant?
What's the difference?
5. Security Considerations
- I assume that, eventually, the RP/IdP language from the OpenID Connect draft
will need to be genericized.
Eve Maler htt
UMA?
>> Not talking about UMA, Bob is not separate between roles in OAUTH,
>> so don't have to redelegate in OAUTH?
>>
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>>
usecase Hardjono rediscribed may not necessarily invloving
> "redelegation", a more general case would be the Babysitter directly show
> delegation to the Teacher and walk the child home.
>
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345
Behalf
>> Of zhou.suj...@zte.com.cn
>> Sent: Thursday, October 11, 2012 4:45 AM
>> To: Eve Maler
>> Cc: oauth@ietf.org WG
>> Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation
>>
>>
>> Hi,Eve
>>
>> "Having an RO li
:
>
> Hi, Eve,
>The requester you described corresponds to Client in OAuth, so it is still
> client initiated delegation, not what Prabath wants.
>
>
>
> Eve Maler
> 2012-10-11 06:54
>
> 收件人
> Prabath Siriwardena
> 抄送
> zhou.suj...@zte.com.cn, &q
ve some pointers..?
>
> Thanks & regards,
> -Prabath
>
> On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler wrote:
> There are a number of implicit actions happening here that ideally should be
> accounted for. If Alice is the RO and Bob is operating the client, then when
>
ronous
presence would be ideal. Otherwise I suspect it's impractical in normal use.
Eve
On 9 Oct 2012, at 6:49 PM, zhou.suj...@zte.com.cn wrote:
>
> Hi，Prabath
>
>
> Prabath Siriwardena
> 2012-10-09 20:35
>
> 收件人
> zhou.suj...@zte.com.cn
> 抄送
&g
from the
> Authorization Server.[just like passing the refresh_token]
>
> WDYT ?
>
> Thanks & regards,
> -Prabath
>
> On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler wrote:
> Hi Prabath,
>
> As far as I know, OAuth itself generally isn't used to let one hum
://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
> ________
Point everyone to StackOverflow with an "oauth" tag
>>
>>
>> -- Justin (who is not volunteering himself to host or moderate the group)
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>&g
bit hairy to put a JSON list inside a
> quoted application data value.
>
> Do we want something like a "capabilities" list which could include
> dynamic_client_registration_supported and perhaps others?
>
> -bill
>
>
>
>
> - Original Message -
>&
-- Mike
>> >>
>> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "> >> Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
>> >
>> > As noted before, here's an example:
>> > <http://green
gt;>> apps-discuss mailing list
>>> apps-disc...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
>> persone
>> indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
>> conoscenza di queste informazioni sono rigorosamente vietate. Qualora
>> abbiate
>> ricevuto questo documento per errore siete cortesemente pregati di darne
>> immediata comunicazione al mittente e di provvedere alla sua distruzione,
>> Grazie.
>>
>> This e-mail and any attachments is confidential and may contain privileged
>> information intended for the addressee(s) only. Dissemination, copying,
>> printing
>> or use by anybody else is unauthorised. If you are not the intended
>> recipient,
>> please delete this message and any attachments and advise the sender by
>> return
>> e-mail, Thanks.
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
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
Eve Maler
that we can get them
> out of the door.
> (And thanks to those who have already read them.)
>
> ___________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler
s,
>>>>> Torsten.
>>>>>
>>>>> Am 16.04.2012 21:04, schrieb Justin Richer:
>>>>>>
>>>>>>>> OK, but with SWD and discovery off the table, can this now be
>>>>>>>> considered to be withi
with some meta-data).
>
> Is this too far fetched?
>
> Ciao
> Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.
e scope to
> user=user_id (where user_id would be the identifier for the user Bob)?
>
> -David
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler
s
>> the resource?
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______
> OAuth mailing list
> OAuth@ietf.org
imple-web-discovery-00
>>
>>
>>
>> We have the following questions:
>>
>> a) Are you interested in any of the above-listed items? (as a reviewer,
>> co-author, implementer, or someone who would like to deploy). It is also
>> useful to know if you think that we shouldn't work on a specific item.
>>
>> b) Are there other items you would like to see the group working on?
>>
>> Note: In case your document is expired please re-submit it.
>>
>> Ciao
>> Hannes & Barry
>>
>> ___
>> 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
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
. Maybe I'm
>>> just scarred by WS-*, but it seems very over-engineered for what it does. I
>>> understand that the communities had reasons for using it to leverage an
>>> existing user base for their specific user cases, but I don't see any
>>> rea
com/hueniverse/node-mac
>> or 'npm install mac'
>>
>> A browser JS lib is available at:
>>
>> https://sled.com/scripts/mac.js
>>
>> Both are used in production.
>>
>> EHL
>>
>>
>>> -Original Message-
>
hub.com/teohm/teohm.github.com/wiki/OAuth
>
> Anyone knows if there is an open source OAuth2 server reference
> implementation that reflects the latest draft 16, and unit-tested
> against the security considerations in section 10?
>
> On Sat, Jun 25, 2011 at 1:02 AM, Eve Ma
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 lis
is to folks you know who might be interested to respond.
Thanks in advance,
Eve
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
___
OAuth mailing list
gt; interface between the authorization server and the protected resource.
>> It could increase the productivity of creating the oauth protected web
>> services when the auth server can be treated as an off the shelf piece
>> of code.
>> Then it would be up t
d nonstandard. :-)
See the "Resource Registration" spec link from our Working Drafts page for more
info; if there's sufficient interest, we could contribute it as an IETF I-D
soonish:
http://kantarainitiative.org/confluence/display/uma/Working+Drafts
solve. This would still allow slimy political manipulation of the process by
>> manipulating the use case list, but that would be progress. It's better to
>> have a protocol that solves a politically-defined set of problems than to
>> have
>> a politically-defined protocol that solves no identified problem.
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
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.xmlgrrl.com/blog
+1
n help prevent a token from being repurposed from one context to
> another, by having a clear (and cryptographically verified) declaration that
> “This is a JSON token”. I understand this motivation and am open to
> discussions on how to best achieve it, while still providing as little
> mechanism
need to be spec'ed -- the question is if the signature spec is in core or a
>> separate spec.
>>
>> For people that don't need signatures, having them separate keeps the core
>> spec simpler. Having a separate spec enables other groups to reuse the
>> si
re of the group.
>
> EHL
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
241 400 730 0,
> http://comlounge.net
> Blog: http://mrtopf.de/blog, Twitter: http://twitter.com/mrtopf
>
> Podcasts:
> Der OpenWeb-Podcast (http://openwebpodcast.de)
> Data Without Borders (http://datawithoutborders.net)
> Politisches: http://politfunk.de/
>
&g
understanding) to serve different clients (or their
> home web apps) on the same host. What about using JRD or XRD? This would
> allow for a client-URL-related discovery.
>
> What means for authentication a client against its home web app. do you
> envision?
>
> regards,
>
ion Tool
> Date: 10 August 2010 12:23:59 PM PDT
> To: e...@xmlgrrl.com
> Cc: c...@comlounge.net, m.p.machu...@ncl.ac.uk
> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00
>
>
> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully
> submitte
> to indicate the resource URL to the authz server. The scope?
>
> regards,
> Torsten.
>
>
>
> Am 02.08.2010 um 02:16 schrieb Eve Maler :
>
>> I'm not sure if you mean "address" as in "handle", or "address" as in
>>
.
Eve
On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote:
> Eve,
>
> how does UMA plan to address resource servers during the OAuth end-user
> authorization process?
>
> regards,
> Torsten.
>
> Am 29.07.2010 02:37, schrieb Eve Maler:
>>
>> B
o the authz server is not an issue.
>> But this implies the client asks for full access to the users media storage.
>> Since our client is a gallery application, it requires the "GET" permission
>> only. How does the client know which of the scope valu
TOS acknowledgement on the initial subscription
> request by a given user, subsequent requests will not provide a
> precondition_uri.
>
> 3) It is also worth exploring this flow as a suitable and more
> flexible alternative to the traditional Web Server flow.
>
>
> Questions? Comments? Suggestions?
>
>
> --
> darren bounds
> dar...@cliqset.com
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
t and will be confusing when used with assertions and
>> other grant types.
>>
>> So I'm open to other ideas but not this one.
>>
>> Note that since this term impacts the name of the current 'grant_type'
>> parameter, changing it means code changes.
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ly you need to separately provide
> a token endpoint as well).
>
> --
> James Manger
> _______
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/x
I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>> ___
>> 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
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
, and that it's pretty much the right
length and organization for its current purpose. So never mind. :)
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
liable shorthand
for an access feature. For read and write and even delete permissions on (say)
identity data accessed by URL, it's pretty much all the expressiveness you
need, and ideally the same documentation easily covers both features and
scopes. For any API that's more
alf a
> resource owner that is not themselves … it then seems the resource owner
> must provide some level of consent outside the OAuth specific flow.
>
> Thanks.
>
> Doug
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve
> M
e the client is acting for itself (the client is
also the resource owner)."
to something like:
"...and autonomous flows where the client is acting on behalf of a different
resource owner."
Thanks,
Eve
On 21 Apr 2010, at 4:43 PM, Eve Maler wrote:
> Tacking this resp
hing to do.
>
> I'm hopeful that either PoCo or the IMAP SASL/OAuth work ends up
> showing how automatic interop is possible.
>
> But I'd hate to have OAuth2 recommend something that doesn't actually work.
>
> Cheers,
> Brian
> __________
Thanks!
On 21 Apr 2010, at 5:12 PM, Eran Hammer-Lahav wrote:
> This is part of the delegation flows so username should be just fine…
>
> EHL
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve
> Maler
> Sent: Wednesday, April 21, 2010 4
is made to get an access token via the User-Agent flow in
>> immediate mode (or with any redirect without prompting the user)
>> -ob now has an access token for Mary and (posts activities, schedules
>> events, gets contacts) as Mary
>> Hilarity ensues
>>
>> Secondary goal: Provide a hint for non-immediate mode
>>
>> On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav
>> wrote:
>> Evan Gilbert proposed a 'username' request parameter to allow the client to
>> limit the end user to authenticate using the provided authorization server
>> identifier. The proposal has not been discussed or supported by others, and
>> has not received a security review.
>>
>> Proposal: Obtain further discussion and support from others, as well as a
>> security review of the proposal. Otherwise, do nothing.
>>
>> EHL
>>
>> ___
>> 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
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
l, you will need to define a bigger set:
> email_read, email_write, contacts_read, contacts_write. On the other hand, if
> a write access is for all authorized resources, you need: email, contacts,
> read, write.
>
> > Given that, returning a single scope value if that is all that makes sense
> > to the
> > resource will likely address many use cases.
>
> This is true when looking at a single resource.
>
> EHL
>
> ___
> 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
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
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
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
t use SAML
> SSO messages to get an Access Token (comparable to OpenID/OAuth hybrid).
>
> Anybody else interested?
>
> paul
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
le specs. SAML
offered guidelines for people writing third-party profiles and extensions, and
a lighter-weight version of this might be nice to have on record if there's any
complexity to it.
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
erberos just be used for your use cases?"
The UMA principles might be able to inform how the OAuth WG makes its case for
why Kerberos doesn't suffice. (If we discover it does, hey, our work here is
done. :-)
Eve
Eve Maler
e...@xmlgrrl.c
Selected thoughts in response:
On 21 Mar 2010, at 3:51 PM, David Recordon wrote:
> Thanks! Comments inline and updated the repo
> (http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a).
>
> On Sun, Mar 21, 2010 at 12:03 PM, Eve Maler wrote:
>
that this or that can be spec'd in the
>> server docs and the client hard coded to the docs; this is fine for
>> some features but not for very general ones that everybody needs to
>> use.
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
access token and then make a refresh call where you ask for a
> token secret. This causes the auth server to mark the token as
> no longer being valid as a bearer token via SSL. This
> performance tradeoff seems realistic given many use cases focus
> on high-volume API transactions and thus the one additional
> request at the onset should be noise. The signature mechanism is
> currently from OAuth 1.0.
>
> Obviously I couldn't have made so much progress so quickly if it weren't for
> WRAP and I hope that 2.0 both addresses the WRAP use cases as well as those
> we all have been discussing here. I hope that I haven't missed anyone who
> contributed to prior work and am happy to add other authors if I have (and
> they wish to be added)!
>
> Thanks,
> --David
>
> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html
>
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ll be in Anaheim Sunday evening, but should
> we try to put a dinner together? 7pm-ish?
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
on manager would ask a requester to produce in order to
prove suitability for getting access. (The authorizing user might be
delegating access to some protected web resource that contains identity claims
about themselves; this is well outside the UMA core protocol.)
bate has been more about whether clients need to use signatures
> when requesting access tokens, or when using access tokens. On one
> side there are people who would prefer bearer tokens, and on the other
> side there are folks who want crypto in various bits of the protocol
> to meet
cal token validation (which ends up looking like
a hybrid remote/local means of validation).
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
re signatures needed?
>>> - What do signatures need to protect?
>>>
>>> Let's try to outline the use cases! Please reply here, so that we have
>>> a good idea of what they are as we move towards the Anaheim WG.
>>>
>> This was a valuable thr
Thanks for your further feedback. Just a couple of comments back (eliding
other portions of the thread):
On 8 Mar 2010, at 2:21 PM, Dick Hardt wrote:
> On 2010-03-05, at 6:57 AM, Eve Maler wrote:
>>>>
>>>> 2c. Currently, WRAP doesn't say anything about how t
More below...
On 4 Mar 2010, at 5:43 PM, Dick Hardt wrote:
> Thanks Eve, comments inserted ...
>
> On 2010-03-04, at 12:51 PM, Eve Maler wrote:
>
>> As requested on today's call, here's a description of the places where UMA
>> seems to need "more&qu
ient/requester along with sending the token for validation. The note you're
responding to just above is this third case.
Eve
>
>
> On 2010-03-04, at 11:01 AM, Eve Maler wrote:
>
>> Folks may be interested to see the following experiment being performed in
>> the
nformation in various ways. It may not be acceptable in some UMA
use cases, e.g., to use replayable tokens. As I promised on the call, I'll
work with the UMA group to research this issue as precisely as possible in
preparation for Anaheim, ideally including specific guidance from
. Please note the final comments in today's UMA telecon minutes for
cautions about additional requirements we have:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com
ed message.
>>>>
>>>> - With regards to #4, how should the challenge identify the token to
>>>> be
>>> used (realm comes free, do we need another)?
>>>>
>>>> - Should a single token support multiple signature algorithms? This
>&
.
>>
>> The terms used in OAuth WRAP are a superset of OAuth 1.0 with changes
>> to provide additional clarity.
>
> I meant to say "agreed, where possible and reasonable". The point of
> this exercise is to make sure that we differentiate where that makes
>
ed for the seminar, got the bridge info, dialed in and nobody
> was there.
> Are there slides available?
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
>> On Behalf Of ext Eve Maler
>> Sent: 25 January, 2010 14
nce/display/uma/Meetings+and+Minutes
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
1 - 100 of 103 matches
Mail list logo
