Hi Hannes, I still think its equally important to have a transport independent binding ..
If you look at the SOAP world, WS-Security is self-contained in the message itself.. and SAML SOAP binding is also another example... Thanks & regards, -Prabath On Wed, Apr 15, 2015 at 1:16 AM, Hannes Tschofenig < [email protected]> wrote: > Hi Prabath, > > the reason we have documents that describe the transport of bearer > tokens/proof-of-possession tokens over the different transports is a > task is more than just conveying a JWT over some protocol. > > There are various documents that specify the transport of OAuth access > tokens over some protocol: > > * Bearer Tokens over HTTPS: > https://tools.ietf.org/html/rfc6750 > > * Proof-of-Possession Tokens over TURN > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13 > > * Bearer Tokens over SASL: > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 > > * Bearer Tokens over CoAP: > https://tools.ietf.org/html/draft-tschofenig-ace-oauth-bt-01 > > * OAuth over SIP: > https://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-02 > > * Then, there is all the work on proof-of-possession tokens that > requires thoughts on how to tie the access token to the request (see > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 or > token binding at > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-00) > > If you look at these documents then you will see that the > characteristics of the underlying protocol matter a lot from a security > point of view. There are also encoding and discovery related aspects > that need to be taken into account as well. > > If someone wants to figure out how to carry OAuth access tokens over > MQTT then they will have to figure out whether there are some additional > considerations to take into account. > > What we should probably doing in this group is to write a guidance > document for using OAuth over <<foo>>. > > Ciao > Hannes > > On 04/15/2015 12:02 AM, Prabath Siriwardena wrote: > > It can be a JSON payload over JMS or even MQTT.. > > > > I have seen some effort to create an MQTT binding for OAuth 2.0 - but > > then again for each transport we need to have a binding.. > > > > But - creating a message level binding would be much better IMHO.. > > > > Thanks & regards, > > -Prabath > > > > On Tue, Apr 14, 2015 at 2:55 PM, John Bradley <[email protected] > > <mailto:[email protected]>> wrote: > > > > Most of the pub sub things I have seen use HTTP transport. Do you > > have a pointer to the protocol? > > > >> On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Thanks John for the pointer - will have look.. > >> > >> I am looking this for a pub/sub scenario.. Having JWT binding > >> would benefit that.. > >> > >> Also - why I want access token to be inside a JWT is - when we > >> send a JSON payload in this case, we already have the JWT envelope > >> and the access token needs to be carried inside.. > >> > >> Thanks & regards, > >> -Prabath > >> > >> > >> > >> > >> > >> On Tue, Apr 14, 2015 at 2:41 PM, John Bradley <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> There is a OAuth binding to > >> SASL > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 > >> > >> Google supports it for IMAP/SMTP, I think the latest iOS and > >> OSX mail client updates use it rather than passwords for Google. > >> I also noticed Outlook on Android using it. > >> > >> The access token might be a signed or encrypted JWT itself. I > >> don’t know that wrapping it again necessarily helps. > >> > >> Yes we should have bindings to other non http protocols. > >> > >> Is there something specific that you are looking for that is > >> not covered by SASL? > >> > >> John B. > >> > >> > >> > >>> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena > >>> <[email protected] <mailto:[email protected]>> wrote: > >>> > >>> At the moment we only HTTP binding to transport the access > >>> token (please correct me if not).. > >>> > >>> This creates a dependency on the transport. > >>> > >>> How about creating a JWT binding for OAuth 2.0..? We can > >>> transport the access token as an encrypted JWT header > >>> parameter..? > >>> > >>> > >>> Thanks & Regards, > >>> Prabath > >>> > >>> Twitter : @prabath > >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > >>> > >>> Mobile : +1 650 625 7950 <tel:%2B1%20650%20625%207950> > >>> > >>> http://blog.facilelogin.com <http://blog.facilelogin.com/> > >>> http://blog.api-security.org <http://blog.api-security.org/> > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] <mailto:[email protected]> > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> -- > >> Thanks & Regards, > >> Prabath > >> > >> Twitter : @prabath > >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > >> > >> Mobile : +1 650 625 7950 <tel:%2B1%20650%20625%207950> > >> > >> http://blog.facilelogin.com <http://blog.facilelogin.com/> > >> http://blog.api-security.org <http://blog.api-security.org/> > > > > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Twitter : @prabath > > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > > > Mobile : +1 650 625 7950 > > > > http://blog.facilelogin.com > > http://blog.api-security.org > > > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
