<Quote>
As I said in response to Joe's message on this thread I think the only
interfaces related to IdentityProvider / AuthenticationAuthority we need
to define are those defined by SAML 2 SSO protocols that are already
being used in the 3.0 specs and that we should not specify a different
interface. Thanks.
</Quote>
Read my lips: No New Interfaces!!!! ;)
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
> -----Original Message-----
> From: Farrukh Najmi [mailto:]
> Sent: Saturday, January 22, 2005 5:35 PM
> To: David Webber (XML)
> Cc: Matthew MacKenzie; Chiusano Joseph;
> Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
>
> David Webber (XML) wrote:
>
> >Gentle folks - I see in the OMAR implementation we have the
> certificate
> >management function. This is very useful and an excellent
> supporting
> >service for Hermes and issuing of CPA certificates to partners, and
> >more.
> >
> >
> For those not familiar with OMAR it is the internal name of
> the freebXML Registry project.
>
> >Is this not the type of abstraction we need here? E.g. a neutral
> >registry service that supports authentication and certificate
> >management et al - but we do not need to specify exactly how this is
> >done - just the types of service provided.
> >
> >
> As I said in response to Joe's message on this thread I think
> the only interfaces related to IdentityProvider /
> AuthenticationAuthority we need to define are those defined
> by SAML 2 SSO protocols that are already being used in the
> 3.0 specs and that we should not specify a different
> interface. Thanks.
>
> >That way implementers can provide extensions to their favourite
> >directory services of choice - while at the same time
> allowing a higher
> >level set of consistent services to be provided by and between
> >registry(s) and associated services.
> >
> >Do we already have the makings of that service interface somewhere?
> >
> >Thanks, DW
> >
> >----- Original Message -----
> >From: "Matthew MacKenzie" <>
> >To: "Chiusano Joseph" <>
> >Cc: "Farrukh Najmi" <>;
> ><>
> >Sent: Sunday, January 23, 2005 3:06 PM
> >Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
> >
> >
> >
> >
> >>At the core of my comment is an understanding of facts in the
> >>enterprise
> >>setting: An ebXML registry WILL NOT be an identity
> provider, unless of
> >>course a very large software company decides to make a product and
> >>successfully market it into many enterprise customers. I
> doubt this
> >>would happen, so we need to be very specific in saying that
> Identity
> >>management is not a registry function. By putting some kind of
> >>abstraction in the specification, we still allow registries
> to support
> >>being a minimal identity provider for small or pilot
> installations but
> >>do not get in the way of serious enterprise installations either.
> >>
> >>I have yet to encounter a paying customer of ebXML registry
> that was
> >>especially happy about having an extra user database to
> support. In
> >>fact, since early days at XML Global, LDAP/ActiveDirectory
> integration
> >>has been a top ask.
> >>
> >>-Matt
> >>Chiusano Joseph wrote:
> >>
> >>
> >>
> >>>Farrukh,
> >>>
> >>>Is the bottom-line question here "should the registry
> should define
> >>>an abstract PrincipalProvider service, and treat external and
> >>>internal users equally as something that may or may not be
> managed by
> >>>the registry?" rather than the way it is described in section 11.7?
> >>>
> >>>If so, I believe the definition/usage of a
> PrincipalProvider service
> >>>should be left as an implementation choice. There may be
> >>>implementations that use a registry only locally, and may
> not need to
> >>>use external identity providers. On a related note, I would not
> >>>consider the registry's management of users (a capability
> since v1)
> >>>as synonymous with an identity provider in terms of what SAML and
> >>>Liberty Alliance enable.
> >>>
> >>>Kind Regards,
> >>>Joseph Chiusano
> >>>Booz Allen Hamilton
> >>>Strategy and Technology Consultants to the World
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Farrukh Najmi [mailto:]
> >>>>Sent: Saturday, January 22, 2005 11:38 AM
> >>>>To:
> >>>>Subject: [regrep] [RS Issue] Internal Vs. External Users
> >>>>
> >>>>Matt sent following comment on section 11.7 that
> describes Internal
> >>>>Vs.
> >>>>External Users.
> >>>>
> >>>>"This section exists, IMO, due to poor design. Why is
> there even a
> >>>>concept of internal and external users and organizations? The
> >>>>registry should define an abstract PrincipalProvider service, and
> >>>>treat external and internal users equally as something
> that may or
> >>>>may not be managed by the registry."
> >>>>
> >>>>The registry historically since version 1 has served in
> the roles of
> >>>>an Identity Provider (manages users) and an
> Authentication Authority
> >>>>( validates user credentials). Thus a registry prior to version 3
> >>>>allowed users to be stored internal to the registry.
> >>>>
> >>>>With version 3 we allow the Identity Provider and Authentication
> >>>>Authority functions to be provided by an external SAML Authority
> >>>>such as an Access Manager service.
> >>>>Depending upon deployment situations a registry MAY manage users
> >>>>itself or leverage an external service to do so.
> >>>>
> >>>>This section is defining the behavior of how to handle
> cases where a
> >>>>user is bweing managed by an external service rather than the
> >>>>registry.
> >>>>
> >>>>If you have a specific proposal on how to address this
> issue please
> >>>>share and we can review the details. Thanks.
> >>>>
> >>>>--
> >>>>Regards,
> >>>>Farrukh
> >>>>
> >>>>
> >>>>To unsubscribe from this mailing list (and be removed from the
> >>>>roster of the OASIS TC), go to
> >>>>http://www.oasis-open.org/apps/org/workgroup/regrep/members/le
> >>>>ave_workgroup.php.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>To unsubscribe from this mailing list (and be removed from
> the roster
> >>>of
> >>>
> >>>
> >the OASIS TC), go to
> >http://www.oasis-open.org/apps/org/workgroup/regrep/members/l
> eave_workgroup.php.
> >
> >
> >>>
> >>>
> >>>
> >>To unsubscribe from this mailing list (and be removed from
> the roster
> >>of
> >>
> >>
> >the OASIS TC), go to
> >http://www.oasis-open.org/apps/org/workgroup/regrep/members/l
> eave_workgroup.php.
> >
> >
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> --
> Regards,
> Farrukh
>
>
