[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Federated Authentication Beyond The Web: Problem Statement and Requirements
On 7/9/10 7:30 PM, Hannes Tschofenig wrote:
Hi Hannes,
sorry for the late response.
np
Interesting statement.
I agree that there are other approaches (and probably everyone would
agree with that; we could even list Kerberos).
However, the MOONSHOT BOF is (if I understood it correctly)
constraint to the mentioned constraints.
hmm, afaik it is a federated authentication BoF, not a Moonshot BoF
The usage of OpenID in SASL/GSS-API (like you pointed out) will be
done in KITTEN independently and has different design constraints.
I think there is a bit of misunderstanding, I gave those just as an
example because I happen to be familiar with them. I am happy with those
drafts being in KITTEN, if only to speed things up. So that is not the
point.
My point is that I'd like the BoF to start open-minded. I believe
federated authentication for non-Web is a large and interesting area. I
would like to make sure that we don't rule out beforehand alternative
approaches. I am happy with a charter as outcome that specifies that the
WG is going to take the Moonshot approach, but imo that should be the
*result* of the BoF, not a *precondition*.
Hope this clarifies the misunderstanding.
Klaas
Ciao Hannes
On 7/6/10 11:15 AM, Hannes Tschofenig wrote:
Hi Hannes,
at the next IETF meeting we are going to have a BOF about
"Federated
Authentication Beyond The Web". In case you have not noticed the
work relates to RADIUS and Diameter.
I wrote this very short problem statement document to explain
the
purpose of the BOF:
http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
Let me know if you find the description useful. Feedback about the BOF
topic would also be appreciated.
I find the description useful, however I would like to challenge
the MUST for RADIUS and/or Diamter. There are a number of
Federated Authentication for applications access protocols out
there, SAML, OpenID and others. RADIUS and Diamter are typically
associated with network access. And while I do see the
attractiveness of marrying the two (and thus leveraging existing
trust fabrics), I wonder why you want to restrict a priori to just
those. As an example draft-cantor-ietf-sasl-saml-ec-00.txt,
draft-lear-ietf-sasl-openid-00, and
draft-wierenga-ietf-sasl-saml-00 specify the use of federated
authentication in a SASL context. And services like eduroam are an
example of the use of just RADIUS to implement federated
authentication for non-web applications. I do understand that it is
not possible nor desirable to take on everything, but let's at
least have this scoping discussion in the BoF.
Klaas
-- to unsubscribe send a message to radiusext-request@ops.ietf.org
with the word 'unsubscribe' in a single line as the message text
body. archive:<http://psg.com/lists/radiusext/>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>