The use cases I have heard of from Justin and Morteza at IIW are based on
federated scenarios. These are not just locally asserted tokens.
Your assertion that the tokens are local and my assertion they are federated
suggests there are things that must be sorted out/understood.
I'm merely implyi
Phil,
The OAuth token used authorize access to the registration endpoint( if one is
required) would be issued by the registration server via some method eg cut and
paste from a developer portal, email or perhaps via OAuth to a Developer API
management application. That is declared out of sc
=nat via iPhone
May 25, 2013 7:16、Phil Hunt wrote:
On 2013-05-24, at 2:54 PM, John Bradley wrote:
I agree with Justin.
If you want tight authentication on the AS that issues the tokens we can
use OAuth for that with short lived tokens granted based on a SAML SSO ,
PIV card or whatever float
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-24, at 2:54 PM, John Bradley wrote:
> I agree with Justin.
>
> If you want tight authentication on the AS that issues the tokens we can use
> OAuth for that with short lived tokens granted based on a SAML SSO , PIV c
I agree with Justin.
If you want tight authentication on the AS that issues the tokens we can use
OAuth for that with short lived tokens granted based on a SAML SSO , PIV card
or whatever floats your boat for authentication.
How the tokens are issued to the OAuth client doing the registration (n
I completely disagree with this assessment. The latest draft (which was just
posted) has new language describing what this token is and what it's for, and I
hope that will clear things up. But even so, let me try to address your
concerns in-line.
On May 24, 2013, at 4:02 PM, Phil Hunt
mailto:p
