On Fri, Apr 21, 2017 at 2:05 PM, Sanjeewa Malalgoda <[email protected]>
wrote:
> As i know oauth 2.0 spec doesn't say anything about validity period per
> dynamic client registered in the system. And if DCR endpoint accept
> optional parameters then we can send application default validity period
> along with DCR request.
>
According to [1].
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
{
"redirect_uris": [
"https://client.example.org/callback";,
"https://client.example.org/callback2";],
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client.example.org/logo.png";,
"jwks_uri": "https://client.example.org/my_public_keys.jwks";,
"example_extension_parameter": "example_value"
}
DCR endpoint accept additional parameters
("example_extension_parameter": "example_value") so we can send
validity period along with DCR request.
[1] https://tools.ietf.org/html/rfc7591#section-3.1
And then when we issue token we have to consider that parameter and
> generate token accordingly. I believe this need to handle at oauth level
> rather doing this in APIM application level. When we move forward we let
> user to use any oauth server to plug as key manager. In that case this
> feature may need to support from others as well(if token validity can pass
> as optional parameter then we will be able to handle this somehow).
>
> One other requirement we got recently was let user to pass desired
> validity period by the time they request token. And if that is not larger
> than default validity period issue token for requested validity period. it.
> In this case also spec do not say anything about validity. As a workaround
> in this case we can revoke token after we used it. But per application
> token validity requirement don't have such workaround.
>
> I think this is good feature to have in our default oauth 2.0
> implementation.
>
> Thanks,
> sanjeewa.
>
> On Fri, Apr 21, 2017 at 1:00 PM, Asela Pathberiya <[email protected]> wrote:
>
>> Hi IS/APIM team,
>>
>> Is $subject in our roadmap ? This seems to be a required features.
>> Different applications may need the different user token expiry time based
>> on their security level.
>>
>> Just heard that; IOT server may has already requirement with that; It is
>> needed to define a token expiry level based on their device type. Say;
>> some device's token may be embedded & these token may have longer expiry
>> time (never expired). Also; some devices type need a less expiry time
>> based on their security policies. It is not sure how we are handled this
>> with APIM feature without $subject. But; this can be easily handled, if
>> we can have such feature inbuilt.
>>
>> Thanks,
>> Asela
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>> +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.
> blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
>
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/
Email: [email protected]
Mobile: +94 (71) 8020933
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
![https://client.example.org/logo.png"](https://client.example.org/logo.png"){kind=link}