Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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:[e-mail]]
Sent: Monday, March 09, 2015 11:10 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 discusses 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.1 we 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: [e-mail]<mailto:[e-mail]>
> 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 <[e-mail]<mailto:[e-mail]>>
> To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
>
>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/saag
>
>

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth