Darren,
As an OAuth 2 provider and consumer as well as someone who's preparing
to build the DiSo interactions my proposal was based on, I would
prefer a single flow that addresses what I feel will be a increasingly
common set of requirements rather than combining two flows designed
for two distinct purposes.
I would rather put this the other way around. Your particular use case
can be implemented by utilizing the building blocks already built into
the specification. Great! That's what I expect from a _standard_. It
provides people with atomic building blocks, they can create their
solutions from. I don't think we should add every possible flow to the
standard.
Even regarding your proposal, much more is possible. You suggest to use
the web server flow for end-user authorization if the assertion flow
failed. Why not using the user agent or the username/password flow
instead? Or any other way of authenticating and authorizing an end-user?
That way, clients can choose the option matching their requirements and
capabilities the most.
Please also note your proposal has an significant impact on access token
lifecycle. In step 1 you propose to issue a none-authorized access
token. This means an authz server must be able to authorize access
tokens after issuance, which is not required currently. Additionally,
resource servers must be able to recognize none-authorized (invalid)
access tokens and refuse any attempt to access resources with an access
token in that state. In my opinion, this makes the tokens lifecycle much
more complex and will not work in all possible setups, especially if the
authorization server issues self-contained tokens. In such a setup, no
direct communication takes place during request processing on the
resource server.
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
