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
> 

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to