If this spec is about providing a single option for doing this as an option
that's fine. If it becomes MTI for using POP tokens at all think that's a
mistake. OAuth 2 provides a framework and one optional token type, Bearer,
which is not MTI. That's a reasonable thing and would work here.
On Sunday, March 8, 2015 10:48 PM, Tirumaleswar Reddy (tireddy)
<tire...@cisco.com> wrote:
#yiv6169713675 #yiv6169713675 -- _filtered #yiv6169713675
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv6169713675
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv6169713675
#yiv6169713675 p.yiv6169713675MsoNormal, #yiv6169713675
li.yiv6169713675MsoNormal, #yiv6169713675 div.yiv6169713675MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv6169713675 a:link,
#yiv6169713675 span.yiv6169713675MsoHyperlink
{color:blue;text-decoration:underline;}#yiv6169713675 a:visited, #yiv6169713675
span.yiv6169713675MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv6169713675
p.yiv6169713675MsoAcetate, #yiv6169713675 li.yiv6169713675MsoAcetate,
#yiv6169713675 div.yiv6169713675MsoAcetate
{margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}#yiv6169713675
p.yiv6169713675msonormal, #yiv6169713675 li.yiv6169713675msonormal,
#yiv6169713675 div.yiv6169713675msonormal
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv6169713675
span.yiv6169713675msohyperlink {}#yiv6169713675
span.yiv6169713675msohyperlinkfollowed {}#yiv6169713675
span.yiv6169713675emailstyle17 {}#yiv6169713675 p.yiv6169713675msonormal1,
#yiv6169713675 li.yiv6169713675msonormal1, #yiv6169713675
div.yiv6169713675msonormal1
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv6169713675
span.yiv6169713675msohyperlink1
{color:blue;text-decoration:underline;}#yiv6169713675
span.yiv6169713675msohyperlinkfollowed1
{color:purple;text-decoration:underline;}#yiv6169713675
span.yiv6169713675emailstyle171 {color:#1F497D;}#yiv6169713675
span.yiv6169713675BalloonTextChar {}#yiv6169713675
span.yiv6169713675EmailStyle27 {color:#1F497D;}#yiv6169713675
.yiv6169713675MsoChpDefault {font-size:10.0pt;} _filtered #yiv6169713675
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv6169713675 div.yiv6169713675WordSection1
{}#yiv6169713675 In this use case RS and AS could be implemented and operated
by different providers, MTI solves the interop issue. -Tiru From: Bill
Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 11:10 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
Explain to me why there should be one other than the desire to over-specify?
Why is one so clearly superior to any of the various possibilities that it
should be mandated? I do not think that there is any clearly superior
mechanism and so making any particular one MTI is pointless and just likely to
cause perfectly good implementations to be out of spec. On Sunday, March 8,
2015 10:24 PM, Tirumaleswar Reddy (tireddy) <tire...@cisco.com> wrote: Hi
Bill, Can you please provide more details why mandating specific key
distribution mechanism is not appropriate especially in case of loosely coupled
systems ? -Tiru From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
I do not believe making any specific key distribution MTI is aproprpiate. On
Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) <tire...@cisco.com>
wrote: Hi Hannes,
http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3discusses
long-term secret shared by the authorization server with the resource server
but does not mention the out-of-band mechanism.
In
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1we
had provided three mechanisms for long-term key establishment. In this use
case RS and AS could be offered by the same provider (tightly-coupled) or by
different providers (loosely-coupled).
Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for
proof-of-possession work as well)
Thanks and Regards,
-Tiru
> -----Original Message-----
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
>
> Hi all,
>
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a
> way
> that is similar to the proof-of-possession work with a new access token
> format.
>
> Ciao
> Hannes
>
> -------- Forwarded Message --------
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +0000
> From: Stephen Farrell <stephen.farr...@cs.tcd.ie>
> To: s...@ietf.org <s...@ietf.org>
>
>
> Hiya,
>
> There's a draft in IESG eval that attracted a bunch of perhaps fundamental
> discusses and comments [1] about its security properties. I think this may be
> one
> where the authors could do with a bit more help from the security
> mafia^H^H^H^H^Hcommunity.
> (I looked at their wg list and only see a v. thin smattering of names I'd
> recognise
> from this list.) So if you're willing and have a little time, please let me
> know
> and/or get in touch with the authors.
>
> And btw - this might not seem so important but I'd worry it may end up being a
> major source of system level vulnerabilities for WebRTC deployments if we get
> it
> wrong and many sites don't deploy usefully good security for this bit of the
> WebRTC story.
>
> Thanks in advance,
> S.
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
>
> _______________________________________________
> saag mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>
_______________________________________________
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
