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:
#yiv3556672566 #yiv3556672566 -- _filtered #yiv3556672566
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv3556672566
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv3556672566
#yiv3556672566 p.yiv3556672566MsoNormal, #yiv3556672566
li.yiv3556672566MsoNormal, #yiv3556672566 div.yiv3556672566MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv3556672566 a:link,
#yiv3556672566 span.yiv3556672566MsoHyperlink
{color:blue;text-decoration:underline;}#yiv3556672566 a:visited, #yiv3556672566
span.yiv3556672566MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv3556672566
span.yiv3556672566EmailStyle17 {color:#1F497D;}#yiv3556672566
.yiv3556672566MsoChpDefault {} _filtered #yiv3556672566 {margin:1.0in 1.0in
1.0in 1.0in;}#yiv3556672566 div.yiv3556672566WordSection1 {}#yiv3556672566 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
