The recent scim notify draft does pub sub using jwts. 

Phil

> On Apr 14, 2015, at 15:02, Prabath Siriwardena <[email protected]> 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]> 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]> 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]> 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]> 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
>>>>> 
>>>>> 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
> 
> 
> 
> -- 
> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to